1591389 - Implement support for Fetch.enable, Fetch.disable, Fetch.requestPaused, and basics for Fetch.continueRequest

Status: RESOLVED WONTFIX

(Remote Protocol :: CDP, enhancement, P2)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This bug will cover the initial work to get the basic features of the Fetch domain implemented. In this case the following two commands are required:

https://chromedevtools.github.io/devtools-protocol/tot/Fetch#method-enable
https://chromedevtools.github.io/devtools-protocol/tot/Fetch#method-disable

Once enabled every network request has to be paused by emitting a Fetch.requestPaused event.

To continue the request the client has to call one of failRequest, fulfillRequest or continueRequest/continueWithAuth, but that is out of scope for this particular bug.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Also see bug 1587426 comment 1 for a possible implementation idea.

Comment 2

[James Graham [:jgraham]]

It sounds like the plan is to make it possible to intercept network requests but not to actually respond to them? That doesn't seem like an obviously useful subset of functionality. I would expect to work with any testsuite we would need at least some of the methods for resuming or explicitly failing the request. Unfortuantely I think this domain is nearly atomic in terms of usefulness; it's hard to pick a subset such that implementing that subset makes sense without also implementing the rest. Maybe continueWithAuth and the methods for getting the response body are outside that subset. fulfillRequest could also be outside a very minimal subset, but I think that's the main use case for this feature, so it would at least need to be a prompt followup.

Comment 3

[James Graham [:jgraham]]

Also I think the intended link may have been bug 1587426 comment 1

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to James Graham [:jgraham] from comment #3)

Also I think the intended link may have been bug 1587426 comment 1

Indeed. Somehow I delete the 6 when splitting the URL.

Otherwise you seem to be right. We should also have at least continueRequest, and let Firefox continue with the original request. Additional parameters for it could be added via bug 1587426. Thanks!

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Jumped up a bit too early here. I just got the Puppeteer examples working, and see some other stuff I would like to get fixed first. Will start on this bug soon.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Note that these missing APIs currently block the Selenium BiDi work to get Firefox supported. One use case here is to bypass basic authentication sites.

Comment 7

[Minu Palaniappan]

Hi there - wanted to get an update on support for this function. Will we be getting network intercept capability in an upcoming Nightly build?

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thanks for asking. So given that the team is working on other more important stuff right now, we won't be able to get support added soon. But when we get started with the implementation of WebDriver BiDi early next year we will definitely have to get that support added. So please stay tuned for a while. Thanks.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

When someone starts to implement these APIs please also have a look at bug 1587426 comment 3.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

We are not going to implement network interception for CDP. Instead we have it now on our focus for the WebDriver BiDi milestone 8 and 9.