1778450 - Can't use "Shift+Tab" to cycle from tabs to last page element when scroll tab arrows are displayed and Firefox View is not before the tabs in the tabstrip

Status: VERIFIED FIXED

(Firefox :: Keyboard Navigation, defect, P2)

Description

[Ellie Lassince]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:104.0) Gecko/20100101 Firefox/104.0

Steps to reproduce:

To reproduce you'll need to :

• Have enough tabs opened to display the scroll tabs arrow
• Have your focus in the address bar
• Press "Shift+Tab" multiple times for the focus to reach the current tab

Actual results:

The ocus will be stuck between the current tab and the "new tab" button.
You still can press "tab" to reach the address bar again.

Expected results:

The focus should have cycled through the whole window and eventually reach the page's last element.

Comment 1

[Colomban Wendling]

Confirmed in both Nightly (104.0a1) and Beta (103.0b5), the focus behaves as expected when all tabs fit in the view, but fail as described when there's not enough room for them all and the arrow buttons appear.

This used to work until "fairly recently" (a few weeks maybe?), and at least ESR91 works fine.

Comment 2

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

The severity field is not set for this bug.
:dao, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[Ina Popescu, Desktop QA]

I've managed to reproduce this issue on the latest versions Nightly 105.0a1 and Firefox 103.0.1 on Windows 10 x64.
Narrowed down the regression range to:

Last good revision: b14241477254436c8f58894e30d154ce1747596f
First bad revision: 03da35913ecdb233ffbbf661cf35324dc225645f
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b14241477254436c8f58894e30d154ce1747596f&tochange=03da35913ecdb233ffbbf661cf35324dc225645f

Comment 4

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

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

Comment 5

[Tim Giles [:tgiles]]

Attachment: Bug 1778450 - Fix tab navigation in toolbar when Firefox View button is not present. r=gijs,jamie

With the addition of the Firefox View button, there is a new tabstop
that is present at the start of the TabsToolbar. When the Firefox View
button is not present, this new tabstop causes navigation to skip over
the selected tab and instead focus the new-tab button. Then, when
trying to navigate backwards from the selected tab, this tabstop at
the front of the TabsToolbar forces us to re-focus the new-tab button
since tabs are not considered a focusable element if we navigated to
a tabstop element, causing us to be stuck in a focus trap.

This patch allows selected tabs to be a valid node when determining
the next focusable element when a tabstop is focused. This restores
the previous behavior of a selected tab being the first focusable
element when navigating forward from the end of web content.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e231687609e3
Fix tab navigation in toolbar when Firefox View button is not present. r=Gijs

Comment 7

[Marian-Vasile Laza]

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

Comment 8

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

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

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox106 to wontfix.

For more information, please visit auto_nag documentation.

Comment 9

[Tim Giles [:tgiles]]

Comment on attachment 9294706 [details]
Bug 1778450 - Fix tab navigation in toolbar when Firefox View button is not present. r=gijs,jamie

Beta/Release Uplift Approval Request

• User impact if declined: Keyboard users can get stuck in a focus trap when navigating backwards through the tabs if the Firefox View button isn't present and there are enough tabs to cause the overflow arrows and button to appear.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It is a one line change that only impacts the keyboard navigation of the toolbar elements
• String changes made/needed:
• Is Android affected?: No

Comment 10

[Pascal Chevrel:pascalc]

Comment on attachment 9294706 [details]
Bug 1778450 - Fix tab navigation in toolbar when Firefox View button is not present. r=gijs,jamie

Approved for 106.0b4, thanks.

Comment 11

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-beta/rev/eddfd5d530f3

Comment 12

[Mathew Hodson]

This feature is disabled by default in Firefox 105 and earlier right?

Comment 13

[:Gijs (he/him)]

(In reply to Mathew Hodson from comment #12)

This feature is disabled by default in Firefox 105 and earlier right?

Firefox View is disabled on 105 and earlier, but the regressing bug 1774742 rode the 103 train. This bug was reported in 104 nightly but confirmed on beta 103 (comment 1) so I don't think "disabled by default" [for Firefox View] comes into it.

Comment 14

[Ina Popescu, Desktop QA]

I've reproduced this issue on Nightly 105.0a1 on Ubuntu 22 and Windows 10 x64.
Using the latest versions Nightly 107.0a1 and Firefox 106.0b4, the issue is no longer reproduceable on Ubuntu 22, Windows 10 and macOS 13 Ventura.