Open Bug 1113522 Opened 6 years ago Updated 1 month ago

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

Categories

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

33 Branch
x86_64
Linux
defect

Tracking

()

People

(Reporter: nsm, Unassigned)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

(Keywords: dev-doc-needed)

Both the WebIDL Exposed= flag and relevant implementation.
registration-attribute.https.html examines this.
Blocks: 1189023
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.
I'm going to take this because I need it for writing some other tests.  Also its a major compat issue!
Assignee: nobody → bkelly
Status: NEW → ASSIGNED
Unfortunately I ran out of time to work on this.
Assignee: bkelly → nobody
Status: ASSIGNED → NEW
Duplicate of this bug: 1311205
Does chrome already implement this?
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.
Duplicate of this bug: 1416671
Summary: Expose ServiceWorker in Workers → Expose ServiceWorker in Workers (aka ServiceWorkerRegistration returns null for all of installing, waiting, active in Workers/ServiceWorkers)
Priority: -- → P3

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!

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.

(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.

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