1898158 - Add support for url argument to "network.continueRequest" command

Status: ASSIGNED

(Remote Protocol :: WebDriver BiDi, task, P2)

Description

[Julian Descottes [:jdescottes]]

Support for the URL parameter will require some additional platform support, at the moment it seems the only way to handle this would be to perform a redirect which is not spec compliant.

Comment 1

[Julian Descottes [:jdescottes]]

File a bug for platform support + check with Alex if this can slip to m12.

Comment 2

[Julian Descottes [:jdescottes]]

Alex: do you think that support the url parameter should be mandatory for puppeteer or can it wait for a later milestone? We currently don't have platform support for this so it might take some time before we can implement this.

Comment 3

[alexrudenko]

I think it might be blocking a couple of tests like "request interception Request.continue should redirect in a way non-observable to page" (the test name is bad but it does test the URL in continueRequest). I think it would be great to support it for completeness of the interception feature.

Comment 4

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

As discussed recently this needs a platform bug to be filed. Julian, can you please create one? Thanks!

Comment 5

[Julian Descottes [:jdescottes]]

Let me start by asking again here, because while working on provideResponse I spotted some APIs which could be helpful.

Kershaw: For WebDriver BiDi network interception, we need to be able to change the url of a request blocked in the "beforeRequestSent" phase, which corresponds to http-on-before-connect at the moment.

We might be able to handle this as an internal redirect, as long as the page cannot detect the redirection. Eg if we navigate to a.com and update the url to b.com via network interception, the window.location.href should still be a.com.

Do you think an internal redirect would work here? It might lead to create duplicated events, but that's something we might be able to handle on our side. Or would we need to add a new API on necko side to support this scenario?

Comment 6

[Kershaw Chang [:kershaw]]

(In reply to Julian Descottes [:jdescottes] from comment #5)

Let me start by asking again here, because while working on provideResponse I spotted some APIs which could be helpful.

Kershaw: For WebDriver BiDi network interception, we need to be able to change the url of a request blocked in the "beforeRequestSent" phase, which corresponds to http-on-before-connect at the moment.

We might be able to handle this as an internal redirect, as long as the page cannot detect the redirection. Eg if we navigate to a.com and update the url to b.com via network interception, the window.location.href should still be a.com.

Do you think an internal redirect would work here? It might lead to create duplicated events, but that's something we might be able to handle on our side. Or would we need to add a new API on necko side to support this scenario?

Yes, I think internal redirect should work here. However, our current RedirectTo API doesn't support internal redirect. I assume we my need to add another function argument for this.
Moreover, we need some changes around here, because the channel doesn't handle redirect immediately after http-on-before-connect.

Comment 7

[Julian Descottes [:jdescottes]]

OK thanks for the info, I'll file a separate bug for this then.
Moving to m12, and setting points.

Comment 8

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

This is not a P2 failure anymore.

Comment 9

[Julian Descottes [:jdescottes]]

Should be unblocked now

Comment 10

[Julian Descottes [:jdescottes]]

Attachment: Bug 1898158 - [bidi] Support url parameter in network.continueRequest