263687 2023-10-25 15:08:56 -0700 notificationClick openWindow goes to PWA root instead of url given 2025-12-02 05:03:23 -0800 1 1 1 Unclassified WebKit WebKit API Safari 17 iPhone / iPad iOS 17 NEW InRadar P2 Major --- 1 mark.romano webkit-unassigned beidson bfulgham conner dernbu dlarocque gillette pataridzegivi rniwa webkit-bug-importer oldest_to_newest 1987583 0 mark.romano 2023-10-25 15:08:56 -0700 Overview: What I'm seeing is similar to https://bugs.webkit.org/show_bug.cgi?id=252544#c18 but I didn't find a logged bug. Steps to Reproduce: Service Worker handles push/notificationclick where the event data can contain a deeplink to open. Install the PWA on Home Screen. Close the PWA app. Tap a Notification with a deeplink in the data. notificationclick calls clients.openWindow() with the deeplink. Actual Results: PWA is opened, but to the pwa root url. Expected Results: PWA is opened to the deeplink url sent to openWindow(). This is the behavior seen if the PWA is already open. Build Date & Hardware: iPhone 14 MPUA3LL/A, iOS Version 17.0.3 (21A360) Additional Information: Contrary to the link above, I know that the service worker is handling the push event because I added "sw-" to the title sent to showNotification(), to confirm. I also am struggling with similar Safari devtools behavior: "In this case, I cannot open the Safari devtools for the service worker running on my phone, it simply isn't listed in the Develop menu under my phone submenu, which is really strange. If I open the app manually then the service worker appears in the menu as expected." notificationclick handler calls a focus() function with parameters extracted from notification.data: function focus(event, parameters) { const destinationUrl = (parameters && parameters.urlPath) ? new URL(parameters.urlPath, appPath).href : appPath; const matchOptions = { type: 'window', includeUncontrolled: false, }; const result = globalThis.clients.matchAll(matchOptions) .then((windowClients) => { // See if there is client for this application already open const matchingClient = windowClients.find((windowClient) => windowClient.url.startsWith(appPath)); if (matchingClient) { logger.info('Found a matching client, focussing it'); if (destinationUrl !== appPath) { return matchingClient.navigate(destinationUrl).then(() => matchingClient.focus()); } return matchingClient.focus(); } logger.info('Opening a new client at', destinationUrl); return globalThis.clients.openWindow(destinationUrl) .catch((error) => { logger.error(`openWindow(${destinationUrl}) failed! ${error})`); }); }); event.waitUntil(result); } 1988097 1 mark.romano 2023-10-27 14:37:14 -0700 We have determined that it is actually the call to matchingClient.navigate(destinationUrl) that is failing with "TypeError: navigate failed" There are no windows open for the service worker, the PWA has been closed, and so has Safari. 1989271 2 webkit-bug-importer 2023-11-01 15:09:17 -0700 <rdar://problem/117817784> 1997160 3 mark.romano 2023-12-05 11:18:40 -0800 Are there any updates on why this isn't working properly? As you can see in my snippet, we have a notificationclick message that can have a URL in it. Basically we want to focus and navigate (or openWindow to the url if no client found). It seems pretty straightforward, but users variably see different behaviors - sometimes the app is focused but doesn't navigate, sometimes the app doesn't even focus. Is there a specific pattern to follow in a notificationclick event handler such that focus/navigate/openWindow always works on ios? 2018601 4 rniwa 2024-03-04 15:42:36 -0800 This is a regression (i.e. used to work on some versions of iOS)?f 2022515 5 mark.romano 2024-03-20 11:28:45 -0700 Are there any updates on this? 2112419 6 mark.romano 2025-04-22 08:24:27 -0700 Are there any updates on this? "It seems pretty straightforward, but users variably see different behaviors" 2162521 7 dernbu 2025-12-02 05:03:23 -0800 On iOS 26.0, I am unable to reproduce this bug, and both calling self.clients.openWindow() and client.navigate() has no issues for me. Any specific iOS / webkit version for which this issue is reproducible?