1432311 - fetch() requests initiated by a serviceworker are missing in the network panel

Status: NEW

(DevTools :: Netmonitor, enhancement, P2)

Description

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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)?

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 3

[Alexandre Poirot [:ochameau]]

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.

Comment 4

[:Harald Kirschner :digitarald]

Perry, are you able to shine some light into what's needed? Not seeing SW requests is a major blocker for debugging the network requests/responses that they make.

I have not been able to see any requests that SWs initiate.

STR: Open Network panel https://firefox-devtools-waiting-sw.glitch.me/ ER: Requests for both /sw.js and /server-version from service-worker.

Comment 5

[:Harald Kirschner :digitarald]

Waiting on a reply from perry, but we might want to dupe this with bug 1267119.

Comment 6

[Perry Jiang [:perry] [no longer employee, use ni?]]

I'm not sure what's needed to show the SW script (/sw.js) in the network monitor - I checked with pref on/off and didn't see /sw.js show up. For the responses provided by a SW, we do still emit the "service-worker-synthesized-response" observer notification, but in the parent process. The comment here from network-observer.js, however, suggests that the topic is only being listened for in content processes, which would explain why /server-version isn't showing up.

Comment 7

[:Harald Kirschner :digitarald]

Honza, does that map to similar Network data that is only available on the parent? If there is a theme, maybe we need to create a meta bug to collect those?

Comment 8

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Perry Jiang [:perry] from comment #6)

The comment here from network-observer.js, however, suggests that the topic is only being listened for in content processes, which would explain why /server-version isn't showing up.

The comment is confusing. I put the following log:

console.log(Services.appinfo.processType);

... just in front of the comment and I can see that the code is executes in both parent and content process. So, we are listening properly for "service-worker-synthesized-response" notifications in both.

However I am only getting that notification for _serviceWorkerRequest https://firefox-devtools-waiting-sw.glitch.me/version and I am not seeing it
for https://firefox-devtools-waiting-sw.glitch.me/sw.js. This sounds like a problem on the platform.

The second issue is that DevTools are filtering out requests that doesn't belong to the current debugged tab and SW requests don't go through that filter since they don't have parent window.
https://searchfox.org/mozilla-central/rev/13b081a62d3f3e3e3120f95564529257b0bf451c/devtools/server/actors/network-monitor/network-observer.js#67 This needs to be solved in DevTools code

Perry, could anyone check why we are not getting the "service-worker-synthesized-response" notification for sw.js?
I am using Harald's example https://firefox-devtools-waiting-sw.glitch.me/

Honza

Comment 9

[:Harald Kirschner :digitarald]

I am not seeing it for https://firefox-devtools-waiting-sw.glitch.me/sw.js. This sounds like a problem on the platform.

I probably conflated this issue for this bug, which perry confirmed in our chat. sw.js not being shown is bug 1267119.

Comment 10

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@Harald, so can we close this, it looks like dup of bug 1267119 ?

Honza

Comment 11

[:Harald Kirschner :digitarald]

@Harald, so can we close this, it looks like dup of bug 1267119 ?

No. In short, bug 1267119 is about showing the browser's request for sw.js; while this bug is about fetch requests made from sw.js.

Comment 15

[Julian Descottes [:jdescottes]]

So we do get notifications about the service worker initiated requests in our Network Observer, however they are all filtered out for a regular tab DevTools Toolbox because of the NetworkObserver filtering logic. But you can see those requests in the Browser Toolbox.

As mentioned in some comments of Bug 1267119, nothing in those requests allows us to identify them as being related to a given browsing context (understandably) so we hide them in the regular DevTools Toolbox. We could somewhat workaround that by using the loadInfo.triggeringRemoteType, which should contain something like webServiceWorker=https://somedomain/ for requests initiated by a service worker and loosely match that against the browsingContext.currentRemoteType, but that will not be very accurate. Might still be an acceptable first step. Otherwise, there are hints about better solutions over in Bug 1267119 comment #12