1977005 - Clicking on a pinned tab steals focus from the content area, throwing off keyboard access

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P1)

Description

[Chris Peterson [:cpeterson]]

Nikki, I bisected this regression to your fix for pinned tab bug 1964534 in Fx 141:

https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=97a2c0d72efd5dc1505123dd65ded8d98a8fd681&tochange=5f5c3d10232a7d3c4da4e4108bd5a4035f6b8524

Steps to reproduce

1. In Firefox 141+ on Windows, open https://mozilla.slack.com/ in a non-pinned tab.
2. Open another website in a second tab.
3. Click focus to the Slack tab.
4. Press Slack's Ctrl + K keyboard shortcut to focus Slack's search field. This works as expected.
5. Now pin the Slack tab.
6. Switch to the second tab.
7. Click focus to the pinned Slack tab.
8. Press Slack's Ctrl + K keyboard shortcut to focus Slack's search field again.

Expected result

Firefox 141 should focus Slacks' search field like Firefox 140 and Chrome, regardless of whether the Slack tab is pinned or not.

Actual result

Firefox 141 focuses Firefox's address bar if the Slack tab is pinned.

I can't reproduce this bug on macOS, where the keyboard shortcut is Cmd + K. I haven't tested on Linux.

I've only tested horizontal tabs, not vertical tabs in the sidebar.

Comment 1

[Chris Peterson [:cpeterson]]

[Tracking Requested - why for this release]:

This bug is a regression in Firefox 141.

Comment 2

[Dão Gottwald [:dao]]

This behavior depends on whether focus is in the content area, which means that this bug affects not just Accel+K but all kinds of content shortcuts and keys (such as scrolling with arrow keys).

When this bug happens, document.activeElement appears to be arrowscrollbox#pinned-tabs-container rather than the selected <browser> element. I suspect the pinned tabs container being focused then makes us avoid focusing the browser here: https://searchfox.org/mozilla-central/rev/6911d55fa5449966d7fd3d70975ded95535b2c8d/browser/components/tabbrowser/content/tabbrowser.js#1585-1589. So we need to figure out how focus ended up on the pinned tabs container in the first place.

Vertical tabs are affected as well, and I suspect that was the case before bug 1964534, but now both vertical and horizontal are affected.

Comment 3

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

The bug is marked as tracked for firefox141 (beta) and tracked for firefox142 (nightly). We have limited time to fix this, the soft freeze is in 2 days. However, the bug still isn't assigned and has low severity.

:cbellini, could you please find an assignee and increase the severity for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 4

[Dão Gottwald [:dao]]

(In reply to Dão Gottwald [:dao] from comment #2)

Vertical tabs are affected as well, and I suspect that was the case before bug 1964534, but now both vertical and horizontal are affected.

Bug 1926683 was the bug specific to vertical tabs.

Comment 5

[Anna Yeddi [:ayeddi]]

Marking it as access-S3, because, if I understood correctly, a keyboard user could still move from the pinned tab with tab or f6 key presses (the focus is not trapped), but it is a big papercut nevertheless.

Comment 7

[Dão Gottwald [:dao]]

Upgrading to S2 after consulting with :jteh.

Comment 8

[Pascal Chevrel:pascalc]

The bug is not assigned, can we target a fix for the planned 141 dot release on August 5?

Comment 9

[Sarah Clements [:sclements] | PTO until Sept 15th]

(In reply to Pascal Chevrel:pascalc from comment #8)

The bug is not assigned, can we target a fix for the planned 141 dot release on August 5?

We'll let you know based on when someone can pick this up and what the fix looks like.

Comment 10

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

:nsharpley, since you are the author of the regressor, bug 1964534, could you take a look?

For more information, please visit BugBot documentation.

Comment 12

[Denys:denyshon]

Just a note, if 1926683 is a duplicate of this bug, Firefox 140 must be affected.

Comment 13

[Dão Gottwald [:dao]]

(In reply to Denys:denyshon from comment #12)

Just a note, if 1926683 is a duplicate of this bug, Firefox 140 must be affected.

It's only affected with vertical tabs. We should still look into uplifting the fix to 140 ESR once we have it, but with only vertical tabs being affected that might be slightly lower priority.

Now that I think about it, let's just keep bug 1926683 separate, so that it remains clear that the horizontal tabs regression is new in 141.

Comment 14

[Dão Gottwald [:dao]]

Now that I looked at bug 1926683 again, that also made me take a closer look at the bug that caused it, bug 1921336. That added tabindex="-1" on the pinned tabs container which was an overlowing <div> at the time, but now it's an <arrowscrollbox> similar to #tabbrowser-arrowscrollbox. Can we just remove tabindex="-1" at this point without regressing bug 1921336?

Comment 15

[Dão Gottwald [:dao]]

Attachment: Bug 1977005 - Remove now unneeded tabindex="-1" from pinned-tabs-container. r=sclements

Comment 16

[Dão Gottwald [:dao]]

Attachment: Bug 1977005 - Remove now unneeded tabindex="-1" from pinned-tabs-container. r=sclements

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

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/8dc7df3906de
https://hg.mozilla.org/integration/autoland/rev/f139e4d78737
Remove now unneeded tabindex="-1" from pinned-tabs-container. r=sclements

Comment 18

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined: Clicking on a pinned tab steals focus from the content area, throwing off keyboard access
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: See https://bugzilla.mozilla.org/show_bug.cgi?id=1977005#c0
• Risk associated with taking this patch: low
• Explanation of risk level: Trivial fix
• String changes made/needed: none
• Is Android affected?: no

Comment 19

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/f139e4d78737

Comment 20

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

The patch landed in nightly and beta is affected.
:dao, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox141 to wontfix.

For more information, please visit BugBot documentation.

Comment 21

[Ciprian Georgiu, Desktop QA - PTO, back on Sep 29]

I was able to repro this issue using STR from comment 0 on an affected Nightly build (2025-07-11), with Win 11.

The issue is verified as fixed on latest Nightly 142.0a1 under Win 11.

Comment 23

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/5c4e012df918
https://hg.mozilla.org/releases/mozilla-release/rev/ff78d3584261

Comment 24

[Ciprian Georgiu, Desktop QA - PTO, back on Sep 29]

This is also verified as fixed on Firefox 141.0.2 under Win 11 x64.