Skip to content
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

Closed
pmeenan opened this issue Jul 14, 2017 · 10 comments
Closed

How to get service worker network events? #36

pmeenan opened this issue Jul 14, 2017 · 10 comments

Comments

@pmeenan
Copy link

pmeenan commented Jul 14, 2017

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.

@pavelfeldman
Copy link
Contributor

pavelfeldman commented Jul 14, 2017

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 Target.attachedToTarget events every time relevant target is created. That would work for Service workers, dedicated workers, out of process iframes.

Note that JavaScript execution for Service worker takes place in its dedicated worker. So that when you get Target.attachedToTarget with SW target, you should immediated call Target.setAutoAttach on it. It will immediately attach its JS worker.

@pmeenan
Copy link
Author

pmeenan commented Jul 14, 2017

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.

@pmeenan
Copy link
Author

pmeenan commented Jul 18, 2017

Works great, thanks for the help.

@martinschierle
Copy link

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) {
for(var info in targets) {
if(targets[info].type=="worker" && extractHostname(targets[info].url)==extractHostname(tab.url)) {
attachTarget = targets[info];
console.log("Attaching debugger to: " + attachTarget.title + " with type " + attachTarget.type + "from url " + attachTarget.url + " with id " + attachTarget.id);
debuggeeId = {targetId: attachTarget.id};
chrome.debugger.attach(debuggeeId,"1.2", attachCallback);
return;
}
}

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');"});

image

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.

@pmeenan
Copy link
Author

pmeenan commented Jan 4, 2018

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?

@pmeenan pmeenan reopened this Jan 4, 2018
@dgozman
Copy link

dgozman commented Jan 4, 2018

This may have regressed with browser side navigation. Let us take a closer look.

@rviscomi
Copy link

rviscomi commented Jan 9, 2018

Did this turn out to be a regression?

@dgozman
Copy link

dgozman commented Jan 16, 2018

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!

@mfalken
Copy link

mfalken commented Feb 1, 2018

@dgozman Regarding off-main-thread-networking, are you referring to off-main-thread fetch or is this an internal DevTools change?

@TimvdLippe
Copy link
Contributor

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 component: Platform>DevTools>Platform. Thanks in advance!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants