Open Bug 1231208 (ServiceWorkers-e10s) Opened 4 years ago Updated 4 days ago
[meta] Service worker e10s redesign
This is a meta bug to track implementation of our service worker e10s refactor.
Talked with Andreas B. and Andrew O. About this. Here's our plan: * Target 61 with our initial release for this assuming we are able to ensure we are stable and do not have breaking implications with devtools * Promise an uplift to ESR for 60.2 with the changes in 61/62 Questions/Risks: * We need to audit asap what affects we will have on devtools and what mitigations could be possible so we can effectively hit 61. * Uplifting this to 60.2, what are the risks/implications there? * What happens if we miss 61? -- Then this pushes to 62, but we should not miss uplift to 60.2 if we can as we will make promises to our enterprise users * What can/will be turned on for 60 that is non-breaking to devtools or anything else? Todo: * Develop language around promising 60.2 to enterprise users.
My big concern here is its looking like we probably won't make FF60 because of devtools fallout. Even without devtools, though, it will be tight. We might be able to enable the pref in nightly by the end of 60, but I'm not super confident. Also consider that I will be out on parental leave for at least half of the FF61 development cycle. If we miss FF60 I'm not sure I can provide any assurance we will hit 61. Also, before we enable the pref in beta we should really perform a shield study to make sure its stable. So even if we have something mostly complete by a certain merge date, we may not ride the trains to release until we can demonstrate its stable. In addition, we don't know what kinds of changes we will need to make after FF60 merge. Given service workers intersects with docshell and necko internals any changes could touch very sensitive areas. So in short, I think this is a risky plan. What feedback are we getting about service workers being missing in ESR? Is some partner asking for it? Just trying to understand what is driving the urgency here. AFAIK service workers don't really address the typical use cases present in enterprises. Personally I would be more comfortable saying we're shooting for FF61 and will assess at that time if an uplift to ESR is feasible.
Can I get a summary of current status?
(In reply to Ben Kelly [Part-time, not reviewing][:bkelly] from comment #4) > My big concern here is its looking like we probably won't make FF60 because > of devtools fallout. Even without devtools, though, it will be tight. We > might be able to enable the pref in nightly by the end of 60, but I'm not > super confident. > We are working right now on building an application panel to promote service worker debugging in the toolbox. For now we didn't plan resources to adapt DevTools to the new architecture. Is the transition supposed to be transparent for us, if not, do you have pointers about what will be impacted here?
(In reply to Julian Descottes [:jdescottes][:julian] from comment #6) > We are working right now on building an application panel to promote service > worker debugging in the toolbox. For now we didn't plan resources to adapt > DevTools to the new architecture. Is the transition supposed to be > transparent for us, if not, do you have pointers about what will be impacted > here? I think the debugger is the most likely thing to be transparent. The things we know will be problematic right now are console reporting and network monitor. Basically, anything that assumes the following may break: 1. Assumes the service worker script runs in the same content process as a window that cares about. (Cares about means controlled by the SW, registered the SW, or is in process of being intercepted by SW.) 2. Assumes the nsIServiceWorker XPCOM interface is in the content process. 3. Assumes interception happens in the content process. We will be moving interception and all SWM stuff like nsIServiceWorker into the parent process. The service worker script may run in a separate process from other windows of the same origin. (If we ever get strict process-per-origin, then they will be in same process again.)
Review dependency tree and remove bugs that are not must-haves for this project.
Question from thomas: Do we have a pref bug for this?
I filed bug 1456995 for enabling the pref on nightly.
For the sake of continuity can we get weekly updates on the metabug on status?
11 months ago
Depends on: 1533753
You need to log in before you can comment on or make changes to this bug.