Open Bug 1432311 Opened 2 years ago Updated 3 months ago
network monitor cannot show network requests form a service worker running in a different process
Currently we show service worker network requests in the network monitor by looking for an nsIObserver topic; "service-worker-synthesized-response". This only works if the devtools network monitor is listening for the topic in the same process as where the service worker notifies the topic. Bug 1431847 is adding a pref that will cause us to start running the service worker in a potentially different process. When this happens we will have to come up with a new way to signal network monitor. One option is to move where we do the NotifyObservers("service-worker-synthesized-response") call. We could potentially do it from HttpChannelChild in the right content process if we have a certain flag set on the channel. If there is a way to somehow tell devtools about it in the parent process, though, that would be better.
Network monitor already listens for "regular" / non-service worker requests in the parent process. A quick skim suggests it might already listen for "service-worker-synthesized-response" in the parent process as well, but a quick test with the pref from bug 1431847 shows the requests do disappear with parent interception. Does parent interception still send "service-worker-synthesized-response" messages (in the parent)?
Currently we fire "service-worker-synthesized-response" in the parent process when "dom.serviceWorkers.parent_intercept" is set to true. We could try to set a flag on the HttpChannelParent that propagates back to the HttpChannelChild, though, and fires the topic in the original content process. That might be the easiest solution here. Also, note that we also still have to solve the problem of the service worker script performing a fetch() or xhr and having that network request show up in the window's network monitor. While the fetch() may be initiated in the parent process with the pref set today, in the future it will be initiated from a content process. The content process will often be a *different* content process from the one owning the window.
You need to log in before you can comment on or make changes to this bug.