Open Bug 1231208 (ServiceWorkers-e10s) Opened 8 years ago Updated 3 months ago

[meta] Service worker e10s redesign

Categories

(Core :: DOM: Service Workers, task, P2)

task

Tracking

()

People

(Reporter: bkelly, Assigned: asuth)

References

(Depends on 8 open bugs, Blocks 5 open bugs)

Details

(Keywords: DevAdvocacy, meta)

Attachments

(2 files)

This is a meta bug to track implementation of our service worker e10s refactor.
Depends on: 1231211
Depends on: 1231213
Depends on: 1231216
Depends on: 1231218
Depends on: 1231220
Depends on: 1182117
Depends on: 1231222
Blocks: 1191367
Depends on: 1231712
Depends on: 1234232
Blocks: 1234232
No longer depends on: 1234232
No longer blocks: 1234232
Depends on: 1234232
Depends on: 1238990
Depends on: 1239113
No longer blocks: 1191367
Blocks: 1283054
Depends on: 1283197
Whiteboard: [e10s-multi:M?]
Whiteboard: [e10s-multi:M?]
Depends on: 1293277
Depends on: 1299271
Depends on: 1300112
Depends on: 1314658
Blocks: 1207778
Blocks: 1345928
Depends on: 1360255
Blocks: 1369476
Keywords: DevAdvocacy
Blocks: 1419727
No longer blocks: 1419727
Depends on: 1428130
No longer depends on: 1231211
Depends on: 1429805
Depends on: 1430139
Depends on: 1430348
Depends on: 1432311
Depends on: 1432640
Priority: -- → P2
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.
Flags: needinfo?(bkelly)
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.
Flags: needinfo?(bkelly)
Depends on: 1441932
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.)
Blocks: 1426401
No longer depends on: 1299271
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?
Flags: needinfo?(bkelly)
Depends on: 1456995
I filed bug 1456995 for enabling the pref on nightly.
Flags: needinfo?(bkelly)
Depends on: 1457157
Blocks: 1344561
No longer depends on: 1283197
Depends on: 1459209
Blocks: 1460286
Depends on: 1462069
Depends on: 1462460
Blocks: 1290958
No longer depends on: 1234232
No longer depends on: 1430348
No longer depends on: 1441932
Depends on: 1226434
Depends on: 1470266
Assignee: nobody → mrbkap
Assignee: mrbkap → bugmail
Assignee: bugmail → nobody
Priority: P2 → --
Assignee: nobody → bugmail
Priority: -- → P2
Blocks: 1217544
Depends on: 1496997
For the sake of continuity can we get weekly updates on the metabug on status?
Flags: needinfo?(bugmail)
Flags: needinfo?(bugmail)
Depends on: 1438945
Assignee: bugmail → mrbkap
Assignee: mrbkap → bugmail
Blocks: 1496997
No longer depends on: 1496997
No longer depends on: 1231220
No longer depends on: 1428130
Depends on: 1520796
Type: defect → task
Depends on: 1568597
No longer blocks: 1581187
Depends on: 1588154
Depends on: 1604543
Depends on: 1472303
Depends on: 1514916

:asuth, I'd assume this meta bug to be an enhancement rather than a task (e10s is an enhancement and this is caused by it, too)?

Flags: needinfo?(bugmail)

Per https://wiki.mozilla.org/BMO/UserGuide/BugFields#bug_type this I think most seems to fall under a refactoring, although it was a refactoring born out of a correctness problem created by e10s. It's not really visible to users directly, other than websites potentially being less glitchy, so I'm not quite sure how that fits in the enhancement regime. Also, reading into enhancement in ways not covered in that doc, an enhancement seems like it is in some ways optional. This refactoring has never been optional.

Flags: needinfo?(bugmail)
Depends on: 1610888
No longer depends on: 1611907
No longer blocks: 1450070
Depends on: 1629643
Depends on: 1625749
Depends on: 1355899
Depends on: 1671389
No longer depends on: 1671389
Depends on: 1701328
No longer blocks: 1290958
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.