Expose mEvaluatingWorker to devtools
Categories
(Core :: DOM: Service Workers, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox73 | --- | fixed |
People
(Reporter: asuth, Assigned: bhackett1024)
References
Details
Attachments
(3 files)
In bug 1228277 we added mEvaluatingWorker
to ServiceWorkerRegistrationInfo, but we failed to expose it via our XPCOM interfaces that are consumed by devtools. This is causing trouble for devtools where registrations appear to have inconsistent state as exposed by the scriptSpec
getter on nsIServiceWorkerRegistrationInfo.
We should:
- Expose evaluatingWorker directly in nsIServiceWorkerRegistrationInfo with installingWorker/waitingWorker/activeWorker
- Add a new helper called NewestIncludingEvaluating() as an expansion on our implementation of Newest noting that newest is part of the spec at https://w3c.github.io/ServiceWorker/#get-newest-worker-algorithm and it must not be mutated to factor in the evaluating worker (now).
- Update SWRI::GetScriptSpec to use the new method above. This is a devtools-ish only introspection method, so it's fine for it to do this.
This then also wants devtools fixups enhancements including:
- Making the registration actor form() aware of the evaluating state.
- Update the front to relay that info. (_getServiceWorker should already handle the actor being from a version that doesn't send the info, I think?)
- Make listAllWorkers aware of the evaluating worker too.
- The fix above for GetScriptSpec moots the workaround at https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/shared/fronts/root.js#171-175
I may be missing other devtools follow-ups that would be appropriate beyond making listAllWorkers() happy.
Reporter | ||
Updated•6 years ago
|
Comment 1•6 years ago
|
||
We have this bug in the debugger, in which the fake registrations that listAllWorkers
does would cause trouble when we have more than 1 service worker https://bugzilla.mozilla.org/show_bug.cgi?id=1598047
One this bug it's fixed, it'd probably fix the root cause for the debugger bug, so let's take that into account when we make listAllWorkers
aware of the evaluating state.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 2•6 years ago
|
||
This is also necessary for bug 1596939. We want to pause service workers early on so that the debugger can attach and breakpoints in the service worker can be hit reliably, but our existing mechanism for normal workers pauses the workers before their main script has started executing. This means that the service worker's evaluating worker will be set, but not its installing/waiting/active worker, and the registration won't have the information the debugger needs to attach to the paused worker.
Assignee | ||
Comment 3•6 years ago
|
||
Updated•6 years ago
|
Assignee | ||
Comment 4•6 years ago
|
||
Depends on D54286
Assignee | ||
Comment 5•6 years ago
|
||
Comment 7•6 years ago
|
||
Backed out 6 changesets (Bug 1595964, Bug 1596939) for causing failures in browser_application_panel_list-domain-workers.js
Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=280136365&resultStatus=testfailed%2Cbusted%2Cexception&revision=65c870147654362c1bfa0013726498943636278c
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=280136365&repo=autoland&lineNumber=987
Backout: https://hg.mozilla.org/integration/autoland/rev/ae020aef580f046a2e5277b726c3e2d4f50734e1
Comment 9•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/cdbe253ae87b
https://hg.mozilla.org/mozilla-central/rev/18ddd988d27b
https://hg.mozilla.org/mozilla-central/rev/053b0bb00fed
Assignee | ||
Updated•6 years ago
|
Description
•