-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
[BUG] Traffic from iframes, nested iframes and service workers not intercepted via CDPSession
/ Fetch.getResponseBody
#21816
Comments
Using
import { Browser, BrowserContext, chromium, Page } from "playwright-chromium";
import * as path from "path";
import * as url from "url";
let browser: Browser;
let context: BrowserContext;
export async function init() {
browser ??= await chromium.launch({
"args": ["--disable-web-security"],
"devtools": true,
"headless": false //!(Boolean(process.env["CI"]) || process.platform === "win32" || Boolean(process.env["DISPLAY"]))
});
context ??= await browser.newContext();
const page = await context.newPage();
page.on("response", async function(response) {
const { hostname, pathname } = new URL(response.url());
let baseName = path.basename(pathname);
const pathName = path.join(pathname.slice(0, -baseName.length));
const fileName = path.join(hostname, pathName, baseName || "index.html");
baseName ||= path.basename(fileName);
try {
const data = await response.text();
console.log("Saving " + response.url() + " as " + baseName);
} catch (error) {
console.error("Failed to get " + response.url());
}
});
await page.goto(url.pathToFileURL(path.resolve("./index.html")).toString());
}
init(); Output:
Although I am still curious to know if this can also be accomplished via a |
@brianjenkins94 First and foremost, we strongly recommend using Playwright API. If you still want to explore DevTools protocol, then you can trace protocol calls that Playwright itself does with the Hope this helps! |
On further inspection Setting |
This allowed me to get the URL of the service worker: context ??= await browser.newContext();
context.on("serviceworker", download); // <--
const page = await context.newPage();
page.on("response", download); |
I have landed at this page after trying to intercept and route WebSocket traffic - it's unclear from the docs whether There is a warning about WebWorker traffic not being sniffed but nothing about the wss protocol not being supported: Will also create an issue and link back to here for reference. |
Use this to monitor network traffic from all nested Iframes. async function monitorNetworkForTarget(target) { client.on('Network.requestWillBeSent', (params) => { client.on('Network.responseReceived', (params) => { browser.on('targetcreated', async (target) => { |
System info
Source code
script.ts
:index.html
:package.json
:Expected
Capture all network traffic, including:
Actual
Output:
Less than what you would expect given a look at the network panel in the Chrome DevTools.
I'm going to compile some more of what I came across while researching this issue and what I tried below, but it seemed like this has been asked frequently enough with no particularly clear, working solution that I hope to at least document it better.
https://stackoverflow.com/questions/70645680/does-chromium-support-intercept-webworker-requests-via-cdp
Mentions using
Target.attachedToTarget
.Someone experiencing the same issue. Notes that they tried sending
Target.setAutoAttach
, which didn't appear to change anything for me. Also notes that they couldn't getTarget.targetCreated
to fire, which I also encountered.Issue could be worked around by using the
--disable-features
flag. Linked resources also talks about howsetAutoAttach
shouldn't be relied on.This is what my current code is based on, although I couldn't get
browser.on('targetcreated')
to fire. Someone towards the bottom mentionsserviceWorkerTarget.setRequestInterception
.Looks like there is some experimental Service Worker-specific network events that I could enable.
Further confirmation that I should be using the experimental Service Worker-specific network events (this section in particular).
Something about iframes and auto-attaching? It sounds like with this PR, frames should auto-attach. The PR talks about frames as being popups, but surely it should apply to anything that creates a new frame.
Another suggestion to use
setRequestInterception
, which is deprecated and suggests you useFetch.enable
instead. I don't fully understand how I would programmatically attach to all of the frames.That's everything that seems relevant.
The text was updated successfully, but these errors were encountered: