Open Bug 1749341 Opened 2 years ago Updated 10 months ago

ServiceWorker isolation breaks early installation of breakpoints

Categories

(DevTools :: Debugger, defect, P3)

defect

Tracking

(Not tracked)

People

(Reporter: jesup, Unassigned)

References

(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).

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.

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...

Depends on: 1651522
Severity: -- → S3
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.