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

[Feature] Target interception #13112

Closed
szmarczak opened this issue Mar 28, 2022 · 6 comments
Closed

[Feature] Target interception #13112

szmarczak opened this issue Mar 28, 2022 · 6 comments

Comments

@szmarczak
Copy link
Contributor

Previous issue: #1101
Related: #13111

There is context.addInitScript, however it doesn't solve all cases where target interception is needed.
For example, if there are CDP messages to be sent. I'm using CDP for response interception, which cannot be done via Playwright yet.

In my opinion, there should be a way to intercept target creation, so Node.js code can be executed (and that enables a wide array of other possibilities) before webpage scripts are ran.

@rwoll rwoll added the triaging label Mar 28, 2022
@rwoll
Copy link
Member

rwoll commented Mar 28, 2022

I'm using CDP for response interception, which cannot be done via Playwright yet.

If your use case is response interception/modification, does https://playwright.dev/docs/network#modify-responses work for you?

@szmarczak
Copy link
Contributor Author

Unfortunately it doesn't, as it uses Node.js HTTP API under the hood - this disables HTTP/2 - the behavior isn't the same.

Fetch.continueResponse works for me. Ideally I'd like to capture all new targets, send some CDP messages, then resume target's work.

@yury-s
Copy link
Member

yury-s commented Mar 29, 2022

Unfortunately it doesn't, as it uses Node.js HTTP API under the hood - this disables HTTP/2 - the behavior isn't the same.

Can you tell us more about your use case and where it fails with the current implementation but works with Fetch.continueResponse?

Fetch.continueResponse works for me.

We added that method during the first iteration on this feature but then moved away from it due to some technical issues. What we could do currently is to (optionally) use http2 instead of https but I'm not sure if that would address your problem given the requirements you mentioned above, we need to better understand your scenario.

@yury-s yury-s closed this as completed Mar 29, 2022
@yury-s yury-s reopened this Mar 29, 2022
@szmarczak
Copy link
Contributor Author

Can you tell us more about your use case and where it fails with the current implementation but works with Fetch.continueResponse?

Automation. Some websites reject requests if the fingerprint doesn't match real browsers.

I'm not sure if that would address your problem

We've developed an npm package that tries to mimic the browser behavior, so we could use that instead. However that's not the best solution.


Target interception would also enable adding init scripts dynamically - this is not limited to response interception. E.g. different pages would have slightly different scripts.

@szmarczak
Copy link
Contributor Author

FYI target interception is currently blocked by https://crbug.com/1070568

@pavelfeldman
Copy link
Member

Why was this issue closed?

Thank you for your involvement. This issue was closed due to limited engagement (upvotes/activity), lack of recent activity, and insufficient actionability. To maintain a manageable database, we prioritize issues based on these factors.

If you disagree with this closure, please open a new issue and reference this one. More support or clarity on its necessity may prompt a review. Your understanding and cooperation are appreciated.

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

No branches or pull requests

4 participants