[Bug]: Service worker event listeners don't work in iOS if app is opened from home screen.

[stefan-krajnik]

Operating System

iOS 16.4.1 (a)

Browser Version

Safari

Firebase SDK Version

9.22.0

Firebase SDK Product:

Messaging

Describe your project's tooling

NodeJs Express

Describe the problem

In the demo app, I listen on messages posted from service worker.
As you can see in the video on desktop Safari it works as intended but it doesn't on iOS (16.4.1 (a) - iPhone 8)

With further investigation I found out event listeners in service workers are not always called,
if I open the app from home screen clicks on notification don't do anything, but if the app is opened by click on notification then it works as intended, meaning clicks on next notification trigger event listeners in service worker.

Screen.Recording.2023-05-18.at.4.21.34.PM.mp4

Steps and code to reproduce issue

• Save the app to Home screen
• Open the app and allow notoficitations, wait for token to be generated
• Close the app
• Reopen the app
• Click "Notify all"
• Click on received notification

Here you can see the reproduction demo https://github.com/stefan-krajnik/fcm-web-push-example
Provide correct firebase config here - https://github.com/stefan-krajnik/fcm-web-push-example/blob/master/index.html#L80
Generate Firebase Admin SDK private key and provide correct path to it - https://github.com/stefan-krajnik/fcm-web-push-example/blob/master/server.js#L5

I deployed the reproduction app to https://fcm-webpush-test.onrender.com

[looptheloop88]

Hi @stefan-krajnik, I'm not sure if I understood the issue well so correct me if I'm wrong here. If the web app is open, you send a notification and the app receives it successfully, you click the notification, it doesn't redirect to the target page.

I checked the code reproduction you've shared and I noticed the way you handle creating and receiving of the notification are different from our documentation and quickstart project. You're not using the onMessage and onBackgroundMessage callbacks available in the Messaging SDK.

Could you please try to use the suggested implementation and see if the issue persists?

[stefan-krajnik]

Hey @looptheloop88 , thanks for replying.

correct me if I'm wrong here. If the web app is open, you send a notification and the app receives it successfully, you click the notification, it doesn't redirect to the target page.
Yes that's correct. But only if the app is open, if app is completely closed, the notification click works properly as expected.

I implemented your suggestion, you can check it out. The behavior is a little bit different from the initial one but the issue is still there, clicking on notification when the app is opened doesn't do anything.

[looptheloop88]

Hi @stefan-krajnik, could you please verify if onMessage callback is triggered when the message is received while the app has focus or is currently opened? I would like to isolate the possible cause, since the notification is created locally and not by the FCM SDK.

[stefan-krajnik]

@looptheloop88
No onMessage is not triggered if the app is opened from the homescreen.

[Heerschop]

I'm experiencing the same problem, however I do not think this has anything to do with Firebase. I have tried several different implementations, and they all have the same issue. For example:

• https://taoshu.in/web/push-demo/
• https://cleverpush.com/en/test-notifications/
• https://docs.wonderpush.com/docs/web-push-notifications-quickstart

I think this problem is related to Safari 16 WebKit API as described in this bug report: https://bugs.webkit.org/show_bug.cgi?id=252544

Here's what happens:
1 - The app launches and starts a page load for the root URL of the web app - https://taoshu.in/web/push-demo/ in this case. This happens in web content process A.
2 - That load has a ScriptExecutionContextIdentifier associated with it. Importantly, this identifier is what the eventual Document will have, but that document does not exist yet.
3 - The networking process is asked to load https://taoshu.in/web/push-demo/. As part of that resource load it is given the context identifier. So the networking process remembers "There is a window client for this URL with this identifier.
4 - The service worker is fired up in web content process B to handle the notification click. This happens right away, before the main page document has really started loading.
5 - In the notification click handler, the SW does a matchAll on clients looking for window clients
6 - That matchAll goes to the networking process, which knows about the eventual client. So it returns that UUID
7 - Back in web content B, the SW has the results of the matchAll and tries to call focus() on the window client.
8 - That focus call is routed to the networking process based on UUID, which knows that the document should be in Web Content process A. So it forwards the call there
9 - In Web Content process A, the focus() attempt tries to look up the Document for that UUID and fails. Remember from step 2, the eventual Document that will be created will have that UUID, but that Document doesn't exist yet.
10 - The failure is routed to Networking, which then routes to Web Content B, and then rejects the focus() promise. Whoops!
11 - Almost immediately after that rejection, data does come in for the main page document, therefore actually creating the Document object in Web Content A, ensuring that a future focus() call would actually work.

A PR has been merged for this: WebKit/WebKit#11848, but it will probably take a while for this to end up in Safari.

[Heerschop]

Just as a note: I have experienced when you add and remove the site from the home screen several times, every so often you will end up with a fully working version, let's say one out of every 15 attempts.

[taoso]

@Heerschop Here is my screen record.

I call the API with data=123. After I click the notification, the data in the bottom of the page changed to 123.

This is done by the following code

navigator.serviceWorker.addEventListener("message", (event) => {
  let wn = document.getElementById("web-notification");
  wn.innerHTML = event.data;
});

So please do not repeat the issue not fixed. Offer the minimal code to reproduce it.
Please offer code use the native API. I do not think there will be anyone willing to debug firebase's framework.

2_1685427976.mp4