Fire WebProgressListener's STATE_START+DOCUMENT+WINDOW for bfcache navigations against the right BrowsingContext
Categories
(Core :: DOM: Navigation, enhancement, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox92 | --- | fixed |
People
(Reporter: ochameau, Assigned: ochameau)
References
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
When doing a regular cross process navigation (not bfcache), going from google.com to mozilla.org, WebProgressListener's STATE_START+IS_DOCUMENT is fired on the BrowsingContext of the previous page, i.e. google.com. i.e. the page we navigate from.
While, with bfCacheInParent enabled, it is fired the other way around.
If you open google.com and then mozilla.org, then if we navigate back to google.com, the STATE_START+IS_DOCUMENT is fired on google.com's BrowsingContext. i.e. the page we navigate to.
This behavior doesn't help DevTools codebase know from which BrowsingContext we are navigating from. I haven't found any other way to retrieve the BC we just navigated from.
Bug 1720304 will help know what is the current BC of the BrowsingContextWebProgress,
and this bug will help have a better current BC.
(I'm opening a dedicated bug in order to land https://phabricator.services.mozilla.com/D119648 independantly of the DevTools changes)
Assignee | ||
Comment 1•3 years ago
|
||
Ensure firing the onStateChange on the BrowsingContext's WebProgress
of the page we navigate from instead of the one we navigate to.
(which was what used to happen before fission/bfcacheInParent)
Pushed by apoirot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/849d5082f329 Fix WebProgress STATE_START+DOCUMENT+WINDOW for bfcache navigations. r=smaug
Updated•3 years ago
|
![]() |
||
Comment 3•3 years ago
|
||
bugherder |
Description
•