ServiceWorker isolation breaks early installation of breakpoints
Categories
(DevTools :: Debugger, defect, P3)
Tracking
(Not tracked)
People
(Reporter: jesup, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
In https://bugzilla.mozilla.org/show_bug.cgi?id=1747261#c9 jdescottes suggested disabling test 4 of browser_dbg-windowless-service-workers when isolation is in use.
This is a followup bug to resolve the startup issues with debugging described there (perhaps just by modifying the test to start a separate serviceworker for the same domain first, so the process already exists).
Comment 1•3 years ago
|
||
I think this is probably a good reason to move ServiceWorker debugging from happening via nsIWorkerDebugger in the content process to nsIWorkerDebugger in the parent process that gets remoted by the ServiceWorker infrastructure from the parent process to the content process over IPC. This could then assist in eliminating the dependency of ServiceWorkers on the main thread.
This was something we originally considered doing at the time but there was no clear benefit and it required work.
Updated•3 years ago
|
Comment 2•3 years ago
|
||
We should be able to fix that at DevTools level by implementing bug 1651522.
For now, DevTools frontend pass the breakpoint very late. The frontend waits for a notification of the server about the creation of a new Service Worker and only then pass the breakpoints.
Bug 1651522 is about moving all this frontend logic to the server codebase so that we have all breakpoint information available from any gecko process. Then it is easy (possible!) to immediately handle service worker no matter where they run and setup breakpoints right away.
I do have WIP patch that I keep trying to finish for months now. I hope to get to land them someday...
Updated•3 years ago
|
Description
•