@brainfoolong opened this Issue on April 13th 2021 Contributor

This bug is just a follow up to a already known bug, but i decided to start a new issue here as the others are marked as resolved or have been merged.


Ok, i can now reproduce this bug with 4.2.1 in Firefox 87.0 on windows. It is still present and still causes errors in our JS error logs. It depends on some specific firefox strict security settings.

Following example:

  • Open any site you want with Firefox
  • Open F12 console
  • Enter and execute this: console.log(navigator.serviceWorker && navigator.serviceWorker.ready)
  • Error occurs

The console command is basically the same as used in matomo here



@diosmosis commented on April 13th 2021 Member

Hi @brainfoolong, I have a couple questions:

  • Does just console.log(navigator.serviceWorker) emit the error?
  • Does navigator.serviceWorker.ready.catch(function () {}) also cause the error?

Also, I'm not completely up to speed on the discussion around this issue, so forgive me if this is obvious, but what's the impact of this bug? Does nothing track because of it or is it just an error in the console?

@brainfoolong commented on April 14th 2021 Contributor

Hi, just the try to use navigator.serviceWorker.ready will cause the exception. It causes error in the javascript console. And also causes errors to be logged when you have a system that log javascript exceptions. So does in our case. It clutters our logs.

This code from matomo does not run on firefox in this case because of this exception, but i don't know what it exactly does.

IMHO, i don't see why matomo try to hook into existing service workers. I read it is for offline tracking but cannot find any relevant code for this, as "matomoSync" does only exist once in the matomo code.

@diosmosis commented on April 14th 2021 Member

Hi @brainfoolong, can you check if 'ready' in navigator.serviceWorker has the same problem?

@brainfoolong commented on April 14th 2021 Contributor

@diosmosis No it does not, but it does not help in this case, at it returns true anyway.

@diosmosis commented on April 14th 2021 Member

That's unfortunate. Thanks for checking.

@brainfoolong commented on April 14th 2021 Contributor

And another note: You can catch this error, but cannot make the error go away. I've tried 3 different methods:

window.addEventListener('unhandledrejection', function (e) {
}, false)

window.addEventListener('error', function (e) {
}, false)



@diosmosis commented on April 14th 2021 Member

Looks like there's a bug in the firefox tracker for this:


If it's possible to detect when that privacy feature is enabled we could avoid the error. Failing that it could be conditionally enabled/disabled in the tracker.

@brainfoolong commented on April 14th 2021 Contributor

Yes, maybe. But, this issues are years old and nobody cares about... Maybe it could be an option in matomo, to prevent offline tracking and so to prevent the use of service worker hooks?

But my question really is, what does this part of the code? I cant see any use of this, as the registered "matomoSync" does no seem to be used anywhere else.

Also, the use for sync is experimental and not ready for production - https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration/sync - This page also list firefox as unsupported. Maybe this code is a bit too experimental for matomo?

I know, it is not really a matomo error, but matomo does generate those errors and i don't see that firefox will fix this anywhere soon.

@diosmosis commented on April 14th 2021 Member

That comment was just to provide information from my research.

Unfortunately, I don't know what this code is for as I wasn't involved in writing or reviewing it, but @tsteur might be able to answer why it's there.

@Findus23 commented on April 14th 2021 Member
@brainfoolong commented on April 14th 2021 Contributor

@Findus23 Thx for clearing this up. This is indeed good to know, as we firewalled our matomo instance and only pass matomo.js and matomo.php through, so this wouldn't even work for us.

Beside that, i think using a highly experimental feature, the sync in service worker, is not that good in a widely used production product, isn't it?

@felix-berlin commented on April 27th 2021

We get similar errors. However, not only in Firefox but also in Safari (iOS and MacOS).

@tsteur commented on April 27th 2021 Member

I'll move this into the current 4.3 milestone so we can investigate further.

@justinvelluppillai commented on July 1st 2021 Contributor

Hi @brainfoolong and @felix-berlin, I have just started to look into resolving this issue and can't reproduce it in Firefox 89. Can you please let me know if you are still seeing the issue, and if so perhaps give me steps and environment to reproduce the issue?

Thanks - maybe some browser updates have fixed this.

@brainfoolong commented on July 2nd 2021 Contributor

Hi @justinvelluppillai . The error still exist. Just run this on any website in F12 -> Console. That's basically the core problem of matomo and the most basic example to reproduce.

You need to enable the settings as stated in post https://github.com/matomo-org/matomo/issues/17454#issue-856875222

@justinvelluppillai commented on July 5th 2021 Contributor

This information has all been mentioned above, but just to clarify this issue:

The relevant setting is

Screen Shot 2021-07-05 at 3 03 48 PM

When it is set, navigator.serviceWorker.ready returns a rejected promise, which we currently don't handle, so firefox shows "The operation is insecure" error.

I have submitted a PR to fix this by handling the rejected promise and silently ignoring it.

@brainfoolong commented on July 5th 2021 Contributor

@justinvelluppillai Thanks, i can confirm that this fix does work.

@justinvelluppillai commented on July 5th 2021 Contributor

Thanks @brainfoolong appreciate you drawing our attention to this and your patience in providing details to get it fixed.

@felix-berlin commented on July 5th 2021

In my case navigator.serviceWorker.ready is undefined.


@felix-berlin commented on July 5th 2021

Is there a other way to force the error?

@Findus23 commented on July 5th 2021 Member

@felix-berlin Do you by chance use any browser extension that modifies theses browser settings?

For me, if I set dom.serviceWorkers.enabled in about:config to false, navigator.serviceWorker becomes undefined.

@felix-berlin commented on July 6th 2021

@Findus23 Yes but only two :)


This Issue was closed on July 5th 2021
Powered by GitHub Issue Mirror