Add support for url argument to "network.continueRequest" command
Categories
(Remote Protocol :: WebDriver BiDi, task, P2)
Tracking
(firefox133 fixed)
Tracking | Status | |
---|---|---|
firefox133 | --- | fixed |
People
(Reporter: jdescottes, Assigned: jdescottes)
References
Details
(Whiteboard: [webdriver:m13], [wptsync upstream][webdriver:relnote])
Attachments
(2 files)
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.
Assignee | ||
Comment 1•8 months ago
|
||
File a bug for platform support + check with Alex if this can slip to m12.
Assignee | ||
Comment 2•8 months ago
|
||
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•8 months ago
|
||
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.
Updated•8 months ago
|
Comment 4•8 months ago
|
||
As discussed recently this needs a platform bug to be filed. Julian, can you please create one? Thanks!
Assignee | ||
Comment 5•8 months ago
|
||
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•8 months ago
|
||
(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
.
Assignee | ||
Comment 7•8 months ago
|
||
OK thanks for the info, I'll file a separate bug for this then.
Moving to m12, and setting points.
Updated•8 months ago
|
Assignee | ||
Comment 9•5 months ago
|
||
Should be unblocked now
Assignee | ||
Comment 10•5 months ago
|
||
Updated•4 months ago
|
Assignee | ||
Comment 11•4 months ago
|
||
Depends on D223377
Comment 12•4 months ago
|
||
Comment 14•4 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/3a7054d9aa63
https://hg.mozilla.org/mozilla-central/rev/0ab5f0ca3958
Assignee | ||
Updated•3 months ago
|
Description
•