Closed Bug 1429714 Opened 2 years ago Closed 2 years ago

serviceWorker registration fails on many pages, "The operation is insecure."

Categories

(Core :: DOM: Service Workers, defect)

57 Branch
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1400678

People

(Reporter: e3405, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20180103231032

Steps to reproduce:

Visiting Sites like 
https://alligator.io/js/intro-progressive-web-apps/
or 
https://www.sitepoint.com/getting-started-with-service-workers/
or
https://serviceworke.rs/push-replace_demo.html

cannot register a ServiceWorker successfully, as an error occurs on the console in the first two cases, and the demo does not work in the last one.
---------------------------------------------------------------
This also happens, if (for debugging purposes) a ServiceWorker tries to install on localhost.
The steps to reproduce are as following:

1) Writing a simple html page, with a service worker installer, and a minimal serviceWorker.
The installer should catch the error.

2) provide the page at localhost (or 127.0.0.1, the bug will occur in both cases)

3) The error will occur, that the  "The operation is insecure." as the following DomException and the serviceWorker will not install.

---------------------------------------------------------
However, a ServiceWorker will install correctly Sites like youtube.com.

This Bug occured on Firefox on Windows and Mac. It was not tested on Linux. No Extensions were installed on Firefox at this moment. 


Actual results:

The registration of ServiceWorkers fails in many cases with the error "The operation is insecure.", even if the same Service Worker registers successfully in Chrome and Edge. This also happens on localhost, and many pages on the Web which are provided via https, as described in the "steps to reproduce" section.

---------------------------------------------------------------
This might also be an issue with LetsEncrypt, as statet here:
https://github.com/mozilla/serviceworker-cookbook/issues/284

However, apparently no bug was filed. 


Expected results:

In all described cases the service Workers should install successfully.
Component: Untriaged → DOM: Service Workers
Product: Firefox → Core
What are your cookie and storage preferences set to?  Open:

  Menu->Options->Privacy&Security

And look at History section.  Does it say "Nightly will: remember history"?
Flags: needinfo?(e3405)
If you try in nightly firefox, do you get a message like this?

  "Failed to register/update a ServiceWorker for scope ‘https://alligator.io/’: Storage access is restricted in this context due to user settings or private browsing mode."

This message was added in FF59.
Note, if you have cookies set to "Keep until I close firefox", we also block service workers.  This is because we don't have support for actually wiping non-cookie storage like Cache API, IDB, etc at the end of the browsing session yet.  See bug 1400678.
Just got burned by this too, Yes my cookies are "Keep until I close Firefox" just goes to prove you guys need to fix/update that setting language LAST YEAR.  Drop the word cookies as the main language in the setting/UI and make it one in a list of things that gets wiped on Firefox close, 

"Persistent storage: Keep until I close Firefox (Block service worker registration)" 

The language of Keep until means that the service worker would still register, but that you'd de-register on Firefox close, but instead you just throw a DOM Insecure error on registration.  What a mess.
(In reply to lists from comment #4)
> The language of Keep until means that the service worker would still
> register, but that you'd de-register on Firefox close, but instead you just

That is bug 1400678 as I mentioned in the last comment.  Its being prioritized.

> throw a DOM Insecure error on registration.  What a mess.

Just to clarify, we don't throw an error.  We reject the promise.  Generally sites need to handle rejected registration promises for a number of reasons.  For example, if the script 404s, etc.
(In reply to Ben Kelly [:bkelly] from comment #3)
> Note, if you have cookies set to "Keep until I close firefox", we also block
> service workers.  This is because we don't have support for actually wiping
> non-cookie storage like Cache API, IDB, etc at the end of the browsing
> session yet.  See bug 1400678.

Yes, thanks, this resolved the issue. :)
Flags: needinfo?(e3405)
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1400678
I think this bug is neiher resolved nor a dupe of 1400678?
This bug is about the fact that using a ServiceWorker throws an error when the cookie setting is "Keep until I close firefox".
The reason service workers are blocked with "keep until I close firefox" is because we don't clear them on browser exit when that setting is enabled.  Leaving storage around when the user thinks its cleared would be a privacy problem.  So this is effectively a dupe of bug 1400678 for now.  Once that is fixed we can relax the service worker permission checks to accept session storage.
bug 1400678 was resolved, so if I understand this thread correctly that means ServiceWorkers can now be installed even with the "Keep until I close Firefox" setting enabled, right?
Its now possible to work on this bug, but some work still needs to be done to relax constraints, write tests, etc.  See bug 1413615.

I stumbled upon this issue as well - and I understand it is being worked on.

In the meantime, I am trying to keep "my console clean"
And I am struggeling to really "catch" the error that is being shown in console when this case is happening

Neither try/catch nor then/catch seems to be able to supress the error warnings in the console.

Am I missing a point? Or is this even intended?

I am still facing the same issue - looks like it has not been fixed yet.

I was also trying to gracefully catch this error and prevent it from appearing on the console. As Peter mentioned try/catch and then/catch does not seem to work. Any pointers?

And was also thinking if there is a work around for this issue? Is there a way we can still make the Service Worker function correctly with the setting "keep until I close firefox" is on?

You need to log in before you can comment on or make changes to this bug.