Bugzilla

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

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