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•2 years ago
|
||
File a bug for platform support + check with Alex if this can slip to m12.
| Assignee | ||
Comment 2•2 years 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•2 years 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•2 years ago
|
Comment 4•2 years ago
|
||
As discussed recently this needs a platform bug to be filed. Julian, can you please create one? Thanks!
| Assignee | ||
Comment 5•2 years 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•2 years 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•2 years ago
|
||
OK thanks for the info, I'll file a separate bug for this then.
Moving to m12, and setting points.
Updated•2 years ago
|
| Assignee | ||
Comment 9•1 year ago
|
||
Should be unblocked now
| Assignee | ||
Comment 10•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 11•1 year ago
|
||
Depends on D223377
Comment 12•1 year ago
|
||
Comment 14•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/3a7054d9aa63
https://hg.mozilla.org/mozilla-central/rev/0ab5f0ca3958
| Assignee | ||
Updated•1 year ago
|
Description
•