Inconsistent behaviour when restoring focus after clicking browser back button
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
People
(Reporter: toraritte, Unassigned)
Details
(Whiteboard: [domcore-bugbash-triaged])
Attachments
(1 file)
|
60.18 KB,
application/json
|
Details |
Steps to reproduce:
-
Go to https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API
-
Search for "single-page application (SPA)"
-
First result is a link, click on it.
-
Click on back button.
-
Check value of
document.activeElement. (-> sometimes <body>, sometimes <a>) -
Click on the very next link (in item 2. in the list below the paragraph; "->Fetches<- new content to display"
-
Check value of
document.activeElement. (-> <body> 19 times out of 20) -
repeating the same steps on https://en.wikipedia.org/wiki/The_cake_is_a_lie will work as expected (see below)
Actual results:
The steps above could be repeated on any link on https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API, and document.activeElement would report different results where the focus is (was). Navigating away and then back from some links produced more <body>-focus than others, but couldn't find a correlation.
On https://en.wikipedia.org/wiki/The_cake_is_a_lie, navigating away and back from any link restored the focus as expected.
Expected results:
I expected link history navigation on https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API as deterministic as I experienced it on https://en.wikipedia.org/wiki/The_cake_is_a_lie (i.e., restore focus on the last active element).
Not sure if this is even a bug, because the HTML spec leaves focus restoration to user agent implementations. Tried to find out whether Firefox has behaviour specifications for this case, but didn't. The only reason I felt encouraged to file this report is because the one filed for Chromium has been confirmed to be a low level bug (https://issues.chromium.org/issues/334275634) which affected JAWS screen reader users. In this case, just want to figure out the reason behind difference in behaviour.
|
||
Comment 1•7 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 3•7 months ago
|
||
https://html.spec.whatwg.org/#restore-persisted-state doesn't say anything about focus. I think this will also depend on whether the previous document was bf-cached (which might explain the inconsistent results).
MDN uses a beforeunload event listener, which MDN says disables bfcache in Firefox. I see https://bugzilla.mozilla.org/show_bug.cgi?id=1815817 and docshell.shistory.bfcache.ship_allow_beforeunload_listeners is true for me on Nightly, so maybe something else in MDN disables bfcache in Firefox. It doesn't in Chrome and the Lighthouse audit says nothing prevents bfcache. :smaug do you have an idea of what it could be? (notRestoredReasons would make this easier to figure out!)
Restoring focus more consistently seems good for users though (like restoring scroll position and form values).
|
||
Comment 4•7 months ago
|
||
Setting SHIPBFCache:5 through about:logging shows:
LogMessages — (SHIPBFCache) Checking https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API
LogMessages — (SHIPBFCache) * unload listener
LogMessages — (SHIPBFCache) +> https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API should be blocked from going into the BFCache
|
|
||
Updated•7 months ago
|
|
||
Updated•7 months ago
|
|
||
Comment 5•5 months ago
|
||
[domcore-bugbash-triaged] Doing domcore random bug triage - valid issue.
Description
•