STR: Go to https://serviceworke.rs/json-cache_demo.html. A "service-worker.js" entry doesn't show up in the network monitor. I'm not sure why this might be, but my hunch is that the information we use to associate the network connections made in tab A versus tab B may be incorrect somehow...
Thanks for the report! I am setting P2 since nobody is having this on the TODO list atm, but sounds important to me to be fixed. Honza
Severity: normal → enhancement
Has STR: --- → yes
Priority: -- → P2
This is kind of that same as bug 1246289, but maybe a bit different. Note, we also don't show any network requests for fetches initiated from within the service worker. We probably need to attach the service worker ID to the nsIChannel somehow and then devtools can use nsIServiceWorkerManager:ShouldReportToWindow() to determine if the toolbox should show that channel.
(In reply to Ben Kelly [:bkelly] from comment #2) > Note, we also don't show any network requests for fetches initiated from > within the service worker. This particular part has been fixed. We still don't show the service worker script load itself, though. (And probably not importScripts() either.)
Created attachment 8852022 [details] [diff] [review] P1: Use aLoadGroup instead of creating a new one
Comment on attachment 8852022 [details] [diff] [review] P1: Use aLoadGroup instead of creating a new one Review of attachment 8852022 [details] [diff] [review]: ----------------------------------------------------------------- r=me because this is an improvement, but I think we may want to some follow-on fixes. For example, I don't think this will show importScripts() or background update requests in the network monitor. It will only show requests triggered from a .register() call. We may need some server worker specific code in devtools to understand a SW loadgroup and call ServiceWorkerManager::ShouldReportToWindow() to figure out if it should be displayed in a particular network monitor: https://dxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsIServiceWorkerManager.idl#228 ::: dom/workers/ServiceWorkerScriptCache.cpp @@ +655,4 @@ > uri, aPrincipal, > nsILoadInfo::SEC_REQUIRE_SAME_ORIGIN_DATA_IS_BLOCKED, > nsIContentPolicy::TYPE_INTERNAL_SERVICE_WORKER, > + aLoadGroup, Just for my own clarification, this is safe to do because we are not actually passing the document's load group. Instead we actually have a separate loadgroup that also happens to point at the document's loadgroup's notification callbacks: https://dxr.mozilla.org/mozilla-central/source/dom/workers/ServiceWorkerManager.cpp#671 So if the window is closed the registration load won't be canceled. I don't think this will help report service worker script loads for update() calls or automatic updates. In those cases we pass nullptr for the load group: https://dxr.mozilla.org/mozilla-central/source/dom/workers/ServiceWorkerManager.cpp#2864 Also, I don't think this change will report network channels for importScripts() loads.
Attachment #8852022 - Flags: review+
Attachment #8852023 - Flags: review+
This seems depends on SW redesign clientId support as well ...
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.