2049307 - Incorrect tab focus after clicking internal link

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Jake Archibald [:jakea]]

https://random-stuff.jakearchibald.com/bug-repros/fragment-focus/

1. Click "click me" - paragraph should highlight
2. Press tab to move focus position

The link after the highlighted paragraph should receive focus. In 152 the other link gets focus.

Regressed in: https://hg-edge.mozilla.org/integration/autoland/rev/da409e4fc87748a2e40333b969d4b25eb51aeba3

https://bugzilla.mozilla.org/show_bug.cgi?id=2034851

Comment 1

[Jake Archibald [:jakea]]

Here's the bit of the spec we're missing https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-the-fragment-identifier:~:text=Move%20the%20sequential%20focus%20navigation%20starting%20point%20to%20target%2E

Chrome, Safari, and Firefox before the regression do the right thing.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 2034851

:ltenenbaum, since you are the author of the regressor, bug 2034851, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Leo Tenenbaum [:ltenenbaum]]

Hmm the <a> is blurred after PresShell::GoToAnchor, so even though GoToAnchor sets the selection which clears the starting point, it gets set to the <a> immediately after. But we can fix this by clearing the starting point again after step 6 here. I suspect the reason other browsers don't have this issue is that they are correctly running step 6 before step 7, but we do it out of order intentionally (https://github.com/whatwg/html/issues/7759).

Comment 4

[Leo Tenenbaum [:ltenenbaum]]

Attachment: Bug 2049307 - Reset focus navigation starting point after running focusing steps for fragment navigation. r=#dom-core

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/6d46630b8a71
https://hg.mozilla.org/integration/autoland/rev/592a06561a8a
Reset focus navigation starting point after running focusing steps for fragment navigation. r=layout-reviewers,emilio

Comment 6

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/60802 for changes under testing/web-platform/tests

Comment 7

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/592a06561a8a

Comment 8

[Leo Tenenbaum [:ltenenbaum]]

Attachment: Bug 2049307 - Reset focus navigation starting point after running focusing steps for fragment navigation.

Original Revision: https://phabricator.services.mozilla.com/D308057

Comment 9

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Quite annoying bug with sequential focus navigation (tab/shift+tab)
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: See comment 0 in the bug
• Risk associated with taking this patch: low
• Explanation of risk level: Change is very small and should only affect sequential focus navigation
• String changes made/needed?: N/A
• Is Android affected?: yes

Comment 10

[Leo Tenenbaum [:ltenenbaum]]

Putting as wontfix in release for now- if we get lots of reports of this I'm happy to request uplift there too though (the patch is very low-risk).

Comment 11

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 12

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/429afe4c74ab
https://hg.mozilla.org/releases/mozilla-beta/rev/908984659926

Comment 13

[Timea Zsoldos [:tzsoldos], Desktop QA]

I have reproduced this issue using Firefox 153.0a1 (build from 2026.05.20) on Windows 11 and macOS 10.15.
I can confirm this issue is fixed, I verified using latest nightly Firefox 154.0a1 and Firefox 153.0b4 (build from treeherder) on Windows 11, macOS 10.15 and Ubuntu 22.

Comment 16

[Jake Archibald [:jakea]]

https://bsky.app/profile/matuzo.at/post/3mpauyxfznc2q

I think we should lift to 152.

Comment 17

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined/Reason for urgency: Focus navigation (tab/shift+tab) bug. We have received several bug reports about this already (and the patch is very low-risk)
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: See comment 0 in the bug
• Risk associated with taking this patch: low
• Explanation of risk level: Very small change, should only affect sequential focus navigation
• String changes made/needed?: N/A
• Is Android affected?: yes

Comment 18

[Leo Tenenbaum [:ltenenbaum]]

Attachment: Bug 2049307 - Reset focus navigation starting point after running focusing steps for fragment navigation.

Original Revision: https://phabricator.services.mozilla.com/D308057

Comment 19

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/d4faced9e237
https://hg.mozilla.org/releases/mozilla-release/rev/e39c605adc0f

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Added to the 152.0.4 relnotes.

Comment 21

[Timea Zsoldos [:tzsoldos], Desktop QA]

I can confirm this issue is fixed, I verified on Firefox 152.0.4 on Windows 11, macOS 10.15 and Ubuntu 22.