Event handler must be added on the initial evaluation of worker script

[stefan-krajnik]

Operating System

macOS Ventura 13.0

Browser Version

Google Chrome Version 120.0.6099.199 (Official Build) (arm64)

Firebase SDK Version

9.22.0

Firebase SDK Product:

Messaging

Describe your project's tooling

React app with Webpack

Describe the problem

I've been seeing these errors in sentry for a while, they come from service worker file even if I register service worker only if isSupported() passes.

This browser doesn't support indexedDb.open() (ex. Safari iFrame, Firefox Private Browsing, etc) (messaging/indexed-db-unsupported).

So I decided to do the same check in service worker but I'm getting these warnings if I call getMessaging asynchronously after isSupported() is resolved (see the screenshot)

Event handler of 'push' event must be added on the initial evaluation of worker script
Event handler of 'pushsubscriptionchange' event must be added on the initial evaluation of worker script.
Event handler of 'notificationclick' event must be added on the initial evaluation of worker script.

Can you please confirm my approach with calling getMessaging asynchronously only if isSupported is correct ? If not what is the correct way using isSupported in service worker to prevent getting the error mentioned at the beginning ?

Steps and code to reproduce issue

• call getMessaging asynchronously in your firebase-messaging-sw.js file

[Santas]

+1

[patrikholcak]

Any news on this? I couldn’t find any official documentation on the usage. Some of the code I found on github uses it the same way OP does, but then it prints the warnings

[stefan-krajnik]

The issue is still present in v10.8.0

[Santas]

@jbalidiong what is the best way to get help regarding this issue?

[jdeepwell]

I ran into this error message too. If I understand correctly, the initialisation of Firebase Push MUST happen in the global scope of the service worker during its initial evaluation – meaning: You cannot call initializeApp/getMessaging asynchronously. They MUST be called immediately when the global scope of the service worker script is first run.

[bgajdos]

+1

[st3ph4nn]

+1

[hsubox76]

It does seem like a bug but I'm not sure what we can do about the asynchronous isSupported() in the service worker at this time. It looks like we can't make it synchronous because of the check for IndexedDB.open() which I think is necessary because the service worker instance needs installations and analytics to work. If that isSupported() is not usable due to service worker requirements, we should probably stop recommending it - will try to dig into this.

We may be able to do something about trying to stop the registration of the service worker in the main app if isSupported() rejects. The original comment said that this doesn't stop the This browser doesn't support indexedDb.open() (ex. Safari iFrame, Firefox Private Browsing, etc) (messaging/indexed-db-unsupported). error.

In the FCM SDK, you usually don't register the service worker yourself - registration of the default service worker happens by default upon calling getToken(), unless you are using a custom service worker (which you would provide in the second arg to getToken). If anyone is registering it themselves, and not providing the registration to getToken() explicitly (getToken(messaging, { serviceWorkerRegistration: myRegistration })) then the SDK is going to try do another registration at that point, which would not be blocked by your conditional. This could be a cause of getting the error despite trying to block the registration? In this case you also need to ensure getToken() (and any other FCM SDK methods) is not called if isSupported() rejects.

Another cause could be that you're in an environment where IndexedDB works in your main browser context but doesn't work in the service worker, which, I don't know of an environment like that, but if you offer any details, maybe we could find out.