Inconsistent fragment in BiDi network events between Chrome and Firefox
Categories
(Remote Protocol :: WebDriver BiDi, defect, P2)
Tracking
(firefox126 fixed)
Tracking | Status | |
---|---|---|
firefox126 | --- | fixed |
People
(Reporter: jdescottes, Assigned: jdescottes)
References
(Blocks 3 open bugs)
Details
(Whiteboard: [webdriver:m10])
Attachments
(1 file)
From the discussion at https://github.com/puppeteer/puppeteer/pull/12122#pullrequestreview-1952776226 , I was trying to check if hash/fragments should be included in BiDi's network events.
Eg if you fetch https://example.com/#foo, what should be the URL in the network.RequestData and in network.responseData. From quickly checking the fetch spec, I think that RequestData should contain the URL with the hash, but ResponseData should only contain https://example.com/.
The getter for the response's URL clearly states:
The url getter steps are to return the empty string if this’s response’s URL is null; otherwise this’s response’s URL, serialized with exclude fragment set to true.
But there's nothing explicitly mentioned for the request's URL getter. So unless it gets stripped somewhere else, I thing the request's URL should be https://example.com/#foo
At the moment, the behavior is inconsistent between Chrome and Firefox. Chrome always removes the fragment, Firefox always includes it.
I suspect that both approaches are wrong, but to be confirmed.
Assignee | ||
Comment 1•8 months ago
|
||
Adding some insights from :jgraham on Matrix:
Unless something is stripping the fragment as part of the request (maybe; I'm not sure), I think stripping the fragment from the response is wrong because we aren't running those getter steps; we're using the internal response class (not the JS wrapper) and that does have the fragment if the original request object's URL had a fragment.
In HTML we're constructing a navigation request at https://html.spec.whatwg.org/#populating-a-session-history-entry:concept-request and that's the URL for the session history entry, which must include a fragment
So the current Firefox implementation could actually be correct.
We should add a wdspec test to cover this once we reached an agreement.
Assignee | ||
Comment 2•8 months ago
|
||
Updated•8 months ago
|
Comment 4•8 months ago
|
||
bugherder |
Updated•8 months ago
|
Description
•