1113522 - Expose ServiceWorker in Workers (aka ServiceWorkerRegistration returns null for all of installing, waiting, active in Workers/ServiceWorkers)

Status: ASSIGNED

(Core :: DOM: Workers, defect, P3)

Description

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

Both the WebIDL Exposed= flag and relevant implementation.

Comment 1

[(no longer active)]

registration-attribute.https.html examines this.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

I think this might be a compat issue worth fixing soon.  It seems somewhat reasonable that a service worker might try to do self.registration.active.postMessage() in an install event to communicate with the worker its replacing.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

I'm going to take this because I need it for writing some other tests.  Also its a major compat issue!

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

Unfortunately I ran out of time to work on this.

Comment 6

[Cătălin Badea (:catalinb)]

Does chrome already implement this?

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

Yes.  They also failed to handle self-postMessage() properly allowing SW's to be kept alive infinitely.  They are fixing now.  We should be careful to avoid that as well.

You may want to wait until I do my clients changes for this.  I will be exposing Worker as a client and may be able to re-use infrastructure.

Comment 9

[Dylan Gattey (he/his)]

Thanks for providing an update Andrew! Hoping to get a question about this answered, if this is an acceptable forum for it. This old bug is still blocking the ability to "silently" refresh a page on Firefox when handling a navigation request in a service worker. Use case: be able to update to latest service worker as a user manually refreshes the page, not as a separate step.

Implementing self.registration.waiting in the worker is necessary to use the technique described in https://redfin.engineering/how-to-fix-the-refresh-button-when-using-service-workers-a8e27af6df68. I'm not sure of another way to activate a waiting worker & refresh the page in one atomic action. Either you get a visible second refresh of the page, or you rely solely on user input. Are there good resources/ways around this that renders this bug less than blocking for this particular usecase?

Any insight into the roadmap here/near-term plans would be fantastic - thanks for everything you guys do!

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

Thank you for upbeat inquiry! We're currently stabilizing a multi-process architectural overhaul of our ServiceWorker implementation. Once that's done this should be on the shortlist of our compat fixes. The abuse scenarios are the primary concern and implementation complexity for this bug (that is, the subject of bug 1544232). If all goes well, we would like to get to this for Firefox 78 (release calendar at https://wiki.mozilla.org/Release_Management/Calendar with 78 becoming nightly as the calendar rolls over to May) but a) I may be overly optimistic and b) we may guard this behind a pref and keep the pref only enabled on nightly and/or beta for an extra release to keep things moving but mitigate risk until we're confident we have tests covering all the attack scenarios.

Comment 11

[Dylan Gattey (he/his)]

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #10)

Thank you for upbeat inquiry! We're currently stabilizing a multi-process architectural overhaul of our ServiceWorker implementation. Once that's done this should be on the shortlist of our compat fixes. The abuse scenarios are the primary concern and implementation complexity for this bug (that is, the subject of bug 1544232). If all goes well, we would like to get to this for Firefox 78 (release calendar at https://wiki.mozilla.org/Release_Management/Calendar with 78 becoming nightly as the calendar rolls over to May) but a) I may be overly optimistic and b) we may guard this behind a pref and keep the pref only enabled on nightly and/or beta for an extra release to keep things moving but mitigate risk until we're confident we have tests covering all the attack scenarios.

Awesome! That's great to hear. Thanks for the detailed update. Will keep an eye out for FF 78. Let me know if there's any testing/help you guys need with an implementation that requires this compat fix.

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

Attachment: Bug 1113522 - Expose ServiceWorker in Workers.

Comment 13

[Andrew Sutherland [:asuth] (he/him)]

Attachment: WIP: Bug 1113522 - Expose ServiceWorker in Workers. r=#dom-workers!

We are able to remove ServiceWorkerVisible and instead use
ServiceWorkersEnabled in its place since we are no longer limiting
where ServiceWorker instances are exposed.