-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to get service worker network events? #36
Comments
SW is a different entity that you need to attach to over the protocol. You can reuse your existing page connection in order to do so. Here is how you do it: let targets = await Target.getTargets();
let swTarget = targets.filter(info => ...); // use info.type and info.url to fine one
Target.attachToTarget({targetId: swTarget.targetId});
Target.sendMessageToTarget({targetId: swTarget.targetId,
message:`{method:'Runtime.evaluate', params: {expression:'console.log(1)'}`}); If you want to save on some of the steps, you can ask Target domain to attach you to all the relevant targets automatically: Target.setAutoAttach({autoAttach: true}); That would emit Note that JavaScript execution for Service worker takes place in its dedicated worker. So that when you get |
Great, thanks. I'll let you know how it goes and if any questions come up. That should be enough to get me going on it. |
Works great, thanks for the help. |
I also ran into this, and the tip from above didn't seem to help. I'm writing a Chrome extension, getting the right target to attach via this code: chrome.debugger.getTargets(function(targets) { This does find the serviceworker, but if I inject and run JS into it, it doesn't know anything from the serviceworker namespace, instead 'self' seem to be of class Window: chrome.debugger.sendCommand(debuggeeId, "Runtime.evaluate",{expression: "console.log(this);console.log('test notification');"}); I also tried the same code as recommended above (which is abit cumbersome to do from an extensions, so I reverted back again), but it seems to just find the same target with the same targetID, console log is also the same. |
Is this still working as expected in 63? I'm seeing some issues where the SW attach events are fired but the network events for the SW don't get captured (maybe it's a bit racy and the network.enable goes in after the actual SW request is already sent). I'm asking it to wait for the debugger on auto attach and send Network.enable before sending it Runtime.runIfWaitingForDebugger but presumably the request for the service worker js doesn't depend on waiting for the debugger. Did it get racier in 63 or was I holding it wrong? |
This may have regressed with browser side navigation. Let us take a closer look. |
Did this turn out to be a regression? |
I looked into this more, and this is probably off-main-thread-networking kicking in. Basically, networking now goes not through ServiceWorker's target, but through it's inner dedicated worker. Could you try this from your end? Sorry for the mess! |
@dgozman Regarding off-main-thread-networking, are you referring to off-main-thread fetch or is this an internal DevTools change? |
This repository is related to Chrome DevTools Protocol, but does not track issues regarding its definition or implementation. If you want to file an issue for the Chrome DevTools Protocol, please open an issue on https://crbug.com under |
It looks like DevTools displays the fetches for the service worker js as well as SW-initiated requests but they aren't exposed at the tab-level for the page in the Network.* events or in the ServiceWOrker.* events.
For the HTTP Archive we use the network.* interface to get the response bodies but we don't currently get the response bodies for SW requests and rely on parsing the netlog to get the timings.
The text was updated successfully, but these errors were encountered: