Create WorkerTargets for service workers
Categories
(DevTools :: Framework, enhancement)
Tracking
(Fission Milestone:Future, firefox122 fixed)
Tracking | Status | |
---|---|---|
firefox122 | --- | fixed |
People
(Reporter: ochameau, Assigned: ochameau)
References
(Depends on 3 open bugs, Blocks 6 open bugs)
Details
(Whiteboard: dt-fission-future)
Attachments
(5 files, 3 obsolete files)
Bug 1633712 will introduce the first framework code in order to create WorkerTargetActor's via the Watcher Actor. This will focus on the regular web page's workers, running in the web page's process.
Bug 1651518 will followup in order to also support parent process workers and shared workers.
Then, the last step would be to support service workers. Like bug 1651518, it may also be only about tweaking a few filtering methods. The filtering would be slightly more complex for service workers as we might have to filter based on the tab's current origin.
And who knows, it may be more complex than just tweaking a few filtering methods.
The filtering around tab's current origin is being explained over here:
https://phabricator.services.mozilla.com/D77425#2416452
3 options are mentioned.
I would personaly go for option C. I think that it would allow debugging SW in all cases from the debugger and stop having you to have to go through about:debugging in order to debug SW startup/shutdown, which may occur after the page navigated.
Harald told me:
Solution C does indeed seem useful, even though SWs don't react to navigation in any special way (apart from the usual tear down they have after inactivity). Other tools like Console and Network persist data; so showing a SW from a prior domain seems not that bad.
Finally, I think that this isn't strictly necessary for shipping fission.
For now, I'll flag this in the reserve list. But I may be wrong and we can revisit this triage.
Comment 1•4 years ago
|
||
Tracking dt-fission-m2-reserve bugs for Fission Beta milestone (M7).
Assignee | ||
Comment 2•4 years ago
|
||
We might want to first change the behavior of SW targets lifecycle via bug 1655439 before implementing this?
Comment 3•4 years ago
|
||
Bulk move of all dt-fission-m2-reserve bugs to Fission MVP milestone.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 4•4 years ago
|
||
Moving "dt-fission-m3-reserve" bugs to "dt-fission-future" because they don't block Fission MVP.
Assignee | ||
Comment 5•2 years ago
|
||
Assignee | ||
Comment 6•2 years ago
|
||
Assignee | ||
Comment 7•1 year ago
|
||
Assignee | ||
Comment 8•1 year ago
|
||
Assignee | ||
Comment 9•1 year ago
|
||
I think we should NOT do that as it prevent debugging SW on navigation to another domain.
But we must probably have some helpful information in the frontend.
Updated•1 year ago
|
Assignee | ||
Comment 10•11 months ago
|
||
Updated•11 months ago
|
Assignee | ||
Comment 11•11 months ago
|
||
Assignee | ||
Comment 12•11 months ago
|
||
The SW wasn't properly unregistered between tests, probably causing failure in other test using this test page.
Comment 13•11 months ago
|
||
Comment on attachment 9359392 [details]
Bug 1651522 - [devtools] Avoid clearing documents when navigating.
Revision D191450 was moved to bug 1861941. Setting attachment 9359392 [details] to obsolete.
Updated•11 months ago
|
Comment 14•11 months ago
|
||
Comment on attachment 9356184 [details]
Bug 1651522 - [devtools] Enable SW debugging in debugger by default
Revision D189825 was moved to bug 1862157. Setting attachment 9356184 [details] to obsolete.
Comment 16•10 months ago
|
||
Comment 17•10 months ago
|
||
Backed out for causing dt failures on devtools/shared/commands/target/tests/browser_target_command_service_workers_navigation.js
Backout link: https://hg.mozilla.org/integration/autoland/rev/8d79f4aa58a79c3c19369e71ee6c6a8094c68c2d
Assignee | ||
Comment 18•10 months ago
|
||
I was having a race condition in the new shared helper to unregister a Service worker.
It should be fixed now.
Comment 19•10 months ago
|
||
Comment 20•10 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/17dc7ba17c9c
https://hg.mozilla.org/mozilla-central/rev/0ac0cfa3ed67
https://hg.mozilla.org/mozilla-central/rev/b44436c89af2
https://hg.mozilla.org/mozilla-central/rev/ac5e5139fe3d
Comment 21•10 months ago
|
||
In bug 1866627 reported against Firefox 122 there are reports of ServiceWorker processes being created/hanging around; is it possible that these changes might lead to a change in the behavior around calls to nsIServiceWorkerInfo::attachDebugger?
Assignee | ||
Comment 22•10 months ago
•
|
||
(In reply to Andrew Sutherland [:asuth] (he/him) from comment #21)
In bug 1866627 reported against Firefox 122 there are reports of ServiceWorker processes being created/hanging around; is it possible that these changes might lead to a change in the behavior around calls to nsIServiceWorkerInfo::attachDebugger?
Oh yes, that's a terrible mistake I did here.
These magic calls to {attach,detach}Debugger
should only be called for Service Workers which actually relates to the currently debugged context.
At least when opening regular DevTools, debugging a Tab, only Service Workers related to that tab will be impacted.
But the issue would still remain for the Browser Toolbox, which is debugging all the service workers.
For that, we may have to further revisit this.
Description
•