Closed Bug 1608554 Opened 10 months ago Closed 8 months ago

Firefox: Unable to initially Access on-screen Controls with the Keyboard after Changing Search Bar Settings from within a New Profile

Categories

(Firefox :: Toolbars and Customization, defect, P1)

72 Branch
defect

Tracking

()

RESOLVED FIXED
Firefox 75
Tracking Status
firefox75 --- fixed

People

(Reporter: elliottabarnes, Assigned: Jamie)

References

(Regression)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

To reproduce - this assumes that a fresh Firefox profile is being used and that NVDA 2019.2.1 is running:

  1. Open Firefox, and navigate to Tools/Options - ensure that NVDA's Focus Mode is enabled at this point

  2. Open the "Search" panel, and either tab or shift + tab out of the Options in this panel and to the other visible controls on the screen - including the address bar and other tab-able items. The idea here is to prove that NVDA is able to navigate to these at this stage

  3. Navigate back to the available options from within the Search panel, and in the selection of radio buttons that controls how the search box is selected, change this selection to "Add search bar in toolbar"

  4. Finally, as before, either tab or shift + tab out of the Search settings, and into the on-screen controls

Actual results:

After changing this setting to force the Search Bar to appear separately to the Address Bar, on-screen controls should still be tab-able - which isn't initially the case after changing the above setting. It's worth noting that if Firefox is then closed and the same profile re-opened, these controls can then be tabbed to as expected. It's also worth mentioning that this isn't a new bug as such, and has been present since at least Firefox 71.

Expected results:

N/A

Hi
I tried to replicate the issue using windows10 64bit and the latest Firefox Nightly release 74.0a1
When i continue to hit tab after selecting the "Add search bar in toolbar" i am able to keep pressing tab and reach the address bar.

Please download the latest Firefox Nightly release from here: https://nightly.mozilla.org/ and retest the problem.

If you still have the issue please create a new profile, you have the steps here:https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Lastly test if the issue is reproducible in safe mode, here is a link that can help you:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Regards
Pablo

Component: Untriaged → Disability Access

The priority flag is not set for this bug.
:asa, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(asa)

(In reply to Pablo from comment #1)

When i continue to hit tab after selecting the "Add search bar in toolbar" i am able to keep pressing tab and reach the address bar.

I am likewise able to do this; i.e. if I hit tab a few times, I do get to the other toolbar controls. However, there are two spurious tab stops which NVDA just reports as "unknown", one before the search bar and one after it. Those shouldn't be there and disappear upon restart. Elliott, is this what you're seeing?

I haven't dug into this, but I think it's because the toolbartabstop elements in the search box don't get tweaked by ToolbarKeyboardNavigator if the search bar is hidden when ToolbarKeyboardNavigator initialises. Assuming I'm right, I'm not quite sure of the best fix here. The ideal fix would be to detect toolbartabstop elements being added and tweak them appropriately, but that would require a MutationObserver and I know Gijs wasn't a fan of me using MutationObservers in a prior iteration of this code. I guess we could re-init ToolbarKeyboardNavigator if the search bar pref is flipped, but that seems very "special case".

Component: Disability Access → Toolbars and Customization
Flags: needinfo?(asa) → needinfo?(elliottabarnes)
Regressed by: 1436086

(In reply to James Teh [:Jamie] from comment #3)

Assuming I'm right, I'm not quite sure of the best fix here. The ideal fix would be to detect toolbartabstop elements being added and tweak them appropriately

We can detect customization changes with a CustomizableUI listener and re-run the detection of the toolbarstop elements.

When ToolbarKeyboardNavigator initializes, it sets aria-hidden and adds a focus listener on toolbartabstop elements.
This is necessary for proper functionality of toolbar keyboard navigation.
However, widgets can be dynamically added by CustomizableUI after ToolbarKeyboardNavigator initializes.
The search bar is one such widget and it does contain toolbartabstop elements.
We now watch for this and initialize any toolbartabstop elements inside added widgets.

Assignee: nobody → jteh

@Jamie - Just to confirm, the behaviour that you described is exactly what I'm seeing. :)

Flags: needinfo?(elliottabarnes)
Pushed by jteh@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/33e43f085390
Initialize toolbartabstops in dynamically added widgets. r=Gijs
Backout by cbrindusan@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c91b81f4d670
Backed out changeset 33e43f085390 for bc failures at browser_searchbar_openpopup.js. CLOSED TREE
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P1
Flags: needinfo?(jteh)
Pushed by jteh@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fad2665c66f8
Initialize toolbartabstops in dynamically added widgets. r=Gijs
Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 75
QA Whiteboard: [qa-75b-p2]
You need to log in before you can comment on or make changes to this bug.