ServiceWorkers-e10s didn't make Firefox 68 so we need to disable ServiceWorkers on ESR. We want a carve-out, however, for Fennec.

The general rationale for disabling on ESR68 continues to be:

• Given imminent implementation changes and expected follow-on changes, it will not be feasible to practically support ServiceWorkers on ESR. Specifically:
  • It's way too risky to convert from child-intercept to parent-intercept on beta, even if we could uplift it.
  • All new development will be against parent-intercept, and e10s child-intercept is very complicated from an analytical perspective. The amount of effort to support ServiceWorkers in a scenario only in use on ESR would be very impractical. (Ex: see bug 1535699 as an example of complexity.)
• The child-intercept ServiceWorker-instance-per-process execution model when run under e10s is not something we want to continue to expose to the web any longer than we have to.
• This is not a regression as far as ESR is concerned. ServiceWorkers first shipped in 44 and were disabled in ESR45, ESR52 (bug 1338144), and ESR60 (bug 1457915).

The rationale for leaving it enabled on Fennc ESR68 is:

• Fennec does not run in e10s mode, meaning that its form of child-intercept is much closer to parent-intercept in terms of content-visible-semantics and how it interacts with the rest of the system. (The scary stuff in child-intercept is in HttpChannelChild/HttpChannelParent and friends.)
• We do not expect to support Fennec ESR68 as long as normal ESR68.
• It would be a functionality regression to remove ServiceWorker support for Fennec, whereas we have never shipped ServiceWorkers on ESR.

Setting tracking+ for Fx68 for now since we don't have ESR-specific tracking flags yet. We'll eventually want to switch this over.

Release Note Request (optional, but appreciated)
[Why is this notable]: Modern apps using service workers won't work on Firefox 68 ESR
[Affects Firefox for Android]: No
[Suggested wording]: Service workers and push notifications remain disabled in Firefox ESR
[Links (documentation, blog post, etc)]: TBD
See also: Firefox 60 ESR Release Notes

Posted site compatibility note: https://www.fxsitecompat.com/en-CA/docs/2019/service-workers-and-push-notifications-are-disabled-on-firefox-68-esr/

We're going to need a patch for this this week.

The intent was never to simply keep service workers off for ESR. This was a temporary thing on 60 because we were told things weren't ready yet.

We already saw people turn these back on for 60 and it's only going to get worse as web apps need them.

Service workers as is work on 68 (clearly they are being used on the web today).

Why wouldn't we just pref on what we have and deal with it for a year?

Try push of patch for review is:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=1c95665221a55a5063ebea67e37a989d16c02368

Previous more extensive try that informed the above is:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7b6cb3e0d0f3b11ed4eec76d5fd7698c225121e8

(In reply to Mike Kaply [:mkaply] from comment #5)

The intent was never to simply keep service workers off for ESR. This was a temporary thing on 60 because we were told things weren't ready yet.

The logic that held then still holds now. The refactoring overhaul has been under way for quite a while and has only begun to come to fruition in Fx69 with ultimate landing happening in 70. See comment 0 here and https://bugzilla.mozilla.org/show_bug.cgi?id=1547023#c0 for some meta-context on the overall concerns.

Why wouldn't we just pref on what we have and deal with it for a year?

There's 2 "deal with it" instances here:

1. Mozilla supporting the ESR68 implementation of ServiceWorkers and child intercept.
2. The web having to deal with the ESR68 implementation of ServiceWorkers.

As one might suspect from how long it's taken us to finally be about to ship the ServiceWorker e10s parent-intercept refactor, we've not had an excess of engineers available on this task. Even if all we do with ESR68 ServiceWorker bugs is WONTFIX them, we're still looking at weeks of human time spent just looking at the bugs to determine we can't support them. And practically speaking, we can't do more than WONTFIX them. We use massively different code-paths when we flip the parent-intercept pref.

The web issue is a bigger one. The major web-compat issues I'm concerned about are:

• Our child-intercept ServiceWorker implementation runs potentially N instances of a ServiceWorker across N processes which can see each other via BroadcastChannel and via state mutation of underlying storage. We're the only browser that does this. All other browsers expose 1 instance across N processes.
  • This leads to some major complications during the ServiceWorker life-cycle related to installation.
• We plan to land the elimination of ServiceWorker registration resurrection during Fx70 which also impacts life-cycle.
• We don't currently expose the ServiceWorker binding on workers.

Having such an idiosyncratic implementation hanging out on the web for an extra year potentially runs the risk of wasting site developer's time and having sites avoid serving ServiceWorkers to any Firefox at all based on user-agent. It also limits the speed at which the spec can move.

Thanks for the detailed info. I guess what I don't understand is aren't people writing ServiceWorkers on the web today using our current implementation?

Hand-waving because we don't gather telemetry on this... Most ServiceWorker usage at this time under Firefox is for push notifications. I think next up is primitive offlining. Many large sites that use ServiceWorkers for more complicated situations (gmail, Facebook) do not enable ServiceWorkers for Firefox. In many cases it's due to us not supporting various APIs in our ServiceWorker implementation (web-locks, navigation-preload). The adoption story is worsened somewhat because although ServiceWorkers notionally enable progressive enhancement, as far as what version of a site you get served, sites prefer to partition based on user-agent because feature detecting ServiceWorkers is bad news for latency.

Which is to say, some people use our implementation, but some people, especially big sites, also explicitly avoid our implementation. Giving them more reasons to avoid using our implementation is something I'd like to avoid.

Comment on attachment 9075806 [details]
Bug 1557565 - Disable Service Workers and push under ESR68 but not under Fennec. r=perry

approved for 68.0esr

https://hg.mozilla.org/releases/mozilla-esr68/rev/6d92e0a48776

https://hg.mozilla.org/releases/mozilla-esr68/rev/193ba9b22019

Included in the draft 68.0esr release notes.