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

Categories

(DevTools :: Netmonitor, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: bkelly, Unassigned, NeedInfo)

References

(Blocks 2 open bugs)

Details

(Whiteboard: SW-CLEANUP)

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)?
Flags: needinfo?(bkelly)
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.
Flags: needinfo?(bkelly)
Product: Firefox → DevTools
Whiteboard: SW-CLEANUP
Flags: needinfo?(bugmail)

Andrew, did anything changed since last comments (i.e. one year ago)?
I was especially wondering if SW were running in their own process now? (sorry I did not track the SW refactoring at all)

From DevTools standpoint, we didn't changed much regarding where we do listen for network requests.
We still listen from both the content process (for SW) and the parent process (for all website requests).
So if the SW requests still happens in the parent process it is only matter of:

  • being able to listen for them if the regular http-on-examine-response/http-on-examine-cached-response/http-on-modify-request are not fired for them. That's why I introduced service-worker-synthesized-response from bug 1158264.
  • be able to distinguish them to flag them as SW requests. For now that's all based around service-worker-synthesized-response.
You need to log in before you can comment on or make changes to this bug.