Wrong navigation id in browsingContext.load if the page performs a fragment or same-document navigation
Categories
(Remote Protocol :: WebDriver BiDi, defect, P2)
Tracking
(firefox133 fixed)
Tracking | Status | |
---|---|---|
firefox133 | --- | fixed |
People
(Reporter: jdescottes, Assigned: jdescottes, NeedInfo)
References
()
Details
(Whiteboard: [webdriver:m13], [wptsync upstream])
Attachments
(2 files)
See https://github.com/puppeteer/puppeteer/issues/13041#issuecomment-2389033038
Potentially regressed by Bug 1879163, but overall the navigation manager is storing the latest navigation id in a map, and this is used by various events (eg domContentLoaded, load etc...) in order to know to which navigation they are linked.
What happens in this scenario, loading google.com is:
- navigate command sent
- navigationStarted event with id A
- same document navigation detected for google.com with id B
- domContentLoaded emitted with navigation id B
- load emitted with navigation id B
Assignee | ||
Comment 1•23 days ago
|
||
It is relatively easy to align Firefox on Chrome's behavior here. The overall idea is that a fragment or same-document navigation should not override the ongoing navigation id of a regular navigation. Those "instant" navigations don't really relate to the upcoming domContentLoaded/load events, so we should just avoid storing them if there is already an ongoing navigation.
Assignee | ||
Comment 2•23 days ago
|
||
Fragment and same-document navigations could override an ongoing navigation and lead browsing
context events such as load and domContentLoaded events to no longer be linked to the expected navigation
id.
Updated•23 days ago
|
Assignee | ||
Comment 3•23 days ago
|
||
Depends on D224385
Assignee | ||
Comment 4•19 days ago
|
||
File a spec issue to check the correctness
Comment 7•16 days ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/9b87f575c8d1
https://hg.mozilla.org/mozilla-central/rev/eb9f5edc1307
Comment 9•4 days ago
|
||
(In reply to Julian Descottes [:jdescottes] from comment #4)
File a spec issue to check the correctness
Hi Julian, I assume this spec issue still needs to be filed?
Description
•