Page position lost when returning to page with an expanded accordion
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
People
(Reporter: mozilla.5vsf3, Unassigned)
References
Details
Attachments
(1 file)
|
6.21 MB,
video/mp4
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:131.0) Gecko/20100101 Firefox/131.0
Firefox for Android
Steps to reproduce:
- Expand an accordion on a page
- Scroll down on some content of the expanded accordion
- Click on a link
- Back to the previous page
Actual results:
The accordion is collapsed. The user lost previous context generating a bad user experience.
Expected results:
The accordion should be expanded. The user will maintain the context and navigation flow.
|
||
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•1 year ago
|
||
Thanks for the report.
I looked into this a bit, and my understanding is that the way this is supposed to work is that when navigating to a new page, Firefox persists its representation of the previous page (specifically, the frame tree) in a cache (called the "bfcache", which stands "back-forward cache"), and when navigating back, the cached frame tree is restored. The state stored in the frame tree includes whether the accordion is collapsed or expanded, so that should be restored as well.
In my local testing of a Wikipedia page, this does work for me (the accordion's state is restored, suggesting a bfcache hit). For some reason this is not happening in your video (what it shows suggests a bfcache miss). I'm going to move this bug to the "DOM: Navigation" component for further investigation of why that might be.
(For completeness, I'll mention that for the scroll position specifically, we have a mechanism for persisting it that's separate from the bfcache, called session history, which works even if a navigation misses the bfcache. However, the "accordion state" on Wikipedia is a less well defined piece of state (the expand/collapse mechanism is sort of an ad-hoc thing implemented in Javascript), so I don't think we can persist that in the session history the way we persist the scroll position.)
|
Reporter | |
Comment 3•1 year ago
|
||
Ok, thank you.
Just in case, I just checked on incognito mode (without extensions) and the issue also happened (on the previous test/screen recording I had uBlock Origin and other extensions installed).
And to add more info if helps, my device is a Samsung Galaxy A55 (released in 2024), 8GB RAM, currently with Android 14, One UI 6.1. Let me know any questions or tests to do.
|
||
Comment 4•1 year ago
|
||
smaug, do we have different bfcache eligibility criteria on Android? Do we look at available RAM or something like that? (The accordion state is restored for me when browsing the Wikipedia mobile view on desktop, and I'm naïvely assuming that Wikipedia is actually serving me the mobile content when claiming to do so.)
|
||
Comment 5•1 year ago
|
||
Mobile view on desktop is quite different to browsing on Android, AFAIK.
But yes, on Android we use still the old session history implementation, on desktop the new.
And there are for example these prefs https://searchfox.org/mozilla-central/rev/0d0eef18ea91e38ddfb82a1ac5d6560a146da5c0/modules/libpref/init/StaticPrefList.yaml#2259-2276
(though, docshell.shistory.bfcache.require_no_opener is for the old implementation, Fission/SHIP requires the same behavior implicitly)
Description
•