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

Steps to reproduce:

I am used to navigate to the search bar using Ctrl+L, Tab, which stopped working some time ago due to accessibility/navigation changes in Firefox. Since then, I have browser.toolbars.keyboard_navigation=false to restore the original behavior. Which worked fine prior to Firefox 83.0.

So, first configure browser.toolbars.keyboard_navigation=false in about:config.
Then start on any page. Press Ctrl+L to move the focus to the address bar.
Press Tab.

Actual results:

The focus moved to some mysterious invisible place. Continuing with another Tab, the focus moves to the browser tabs (pun not intended), next few Tabs move through the individual icons (shield, padlock, permissions, …) on the left-hand side of the address bar, another Tab goes back to the address bar. But something is different now, since another Tab goes finally to the search bar.

Expected results:

The focus should move to the search bar.

I have attempted this issue's reproduction on Ubuntu 20, Windows 10 and Fedora 33, and all three operating systems have the same behavior:

1. In Firefox Release 81, the address bad lacked the buttons from the right of the address bar (as seen in later versions), so after having enabled the search bar, if the user pressed CTRL+L and then Tab, the focus would be on the Search Bar.
2. In the later versions, the same steps to reproduce result in having the first icon from the address bad to be selected (Toggle reader view or Page actions buttons), after this being needed to tab Tab once again for the search bar to be in focus...

Furthermore, I would like to point out that having pressed CTRL + E will focus the Search Bar directly.

Do you consider this to be a decent procedure or would you like to try to find a workaround to disable those address bar buttons?

Have a good one!

You are explaining the (default) behavior of Firefox (since about 2019-05, I think). However, as I wrote above, I have changed the browser.toolbars.keyboard_navigation setting (see e.g. https://support.mozilla.org/en-US/kb/access-toolbar-functions-using-keyboard) to use the previous functionality of Tab skipping the icons on the right-hand side of the address bar and going directly to the search bar. Which is what broke in FF83. You need to toggle the config variable to false to test the problem.

I guess I should learn to use Ctrl+E instead of Ctrl+L, Tab, because I am obviously swimming against the current. But the muscle memory is there and it will be a bit of pain to relearn. (And as the above-linked page shows, I am not the only one.)

But even then, the setting should either be removed, or it should be working, IMHO. Right now it does something broken, especially the mysterious place where the focus disappears after the first Tab seems to be an obvious bug.

Considering that Firefox Release v67 was released in 21st of September 2019 (https://wiki.mozilla.org/Release_Management/Calendar), I have to say that there is no point in comparing to the behavior of such an old version of the browser when talking about an enhancement like this.

I can confirm the information that:

• in Nightly v66, using the combination of CTRL+L, then Tab, would focus the search bar.
• in Nightly v67, using the CTRL+L and the Tab key did not even switch to the Search Bar, BUT adding the pref browser.toolbars.keyboard_navigation=false did work as it did in the older version, as described in Mozilla support (https://support.mozilla.org/en-US/kb/access-toolbar-functions-using-keyboard).
• in Firefox v83 and Nightly v85.0a1, using the CTRL+L and the Tab key did not even switch to the Search Bar, but to the first button from the right of the address bar, having needed to tap the Tab key again (which could be considered a decent hotkey). Furthermore, switching the browser.toolbars.keyboard_navigation pref to false made behavior even worse, on top of making the Mozilla Support page incorrect or out of date.

Having said all the above, I will confirm this issue and set its component to Toolbars and Customization. If incorrect, please set a more appropriate one, rather than reverting it to Untriaged.

Thank you, Petr Kadlec!

This change was the thing I directly noticed in version 83 because it changed the way to navigate by keyboard.

According the the list of keyboard shortcuts there are 2 other combinations to focus on the address bar: Alt+D and F6.

The handling of Alt+D is the same as Ctrl+L. But F6 is different. Pressing F6 focuses on the address bar, but without showing the list of URL's. And pressing Tab will change focus on the search box. This tab order is like it was before version 83.

I think this might actually be a bug to go into Address Bar. Let's see what the Search team thinks.

I don't think this was an intentional change, so I'm marking this as a regression.

I have performed a regression with the following steps:

1. Open profile with pref browser.toolbars.keyboard_navigation=false.
2. Add search bar in toolbar.
3. Tap CRTR+L hotkey.
4. Tap Tab key.
   Good build: Focus is in the Search bar.
   Bad build: Focus is "lost in space".

Results:

2020-12-10T00:46:34: INFO : platform_version: 81.0a1
2020-12-10T00:46:37: INFO : Can't find symbol 'eglSwapBuffersWithDamageEXT'.
2020-12-10T00:47:21: INFO : Narrowed inbound regression window from [62990ef4, 49ba9675] (3 builds) to [fad66448, 49ba9675] (2 builds) (~1 steps left)
2020-12-10T00:47:21: DEBUG : Starting merge handling...
2020-12-10T00:47:21: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=49ba9675c183ccbb6eb9e94a779e470709d0aef1&full=1
2020-12-10T00:47:34: DEBUG : Found commit message:
Bug 1658326 - Enable one-off update2 prefs in Nightly. r=adw
Differential Revision: https://phabricator.services.mozilla.com/D86768
2020-12-10T00:47:34: DEBUG : Did not find a branch, checking all integration branches
2020-12-10T00:47:34: INFO : The bisection is done.
2020-12-10T00:47:34: INFO : Stopped

Let me investigate this.

This is due to the fact CTRL+L now opens the Address Bar panel on Top Sites.
Tab is then captured by the panel itself. To move to the next widget you must first close the panel with ESC.
Alternatively you can disable Top Sites in the Privacy Settings, then the panel won't open and won't capture Tab.

Question for the reporter: could you please confirm that if the panel is closed, or if you disable Top Sites, everything works as expected?

Now, the problem here is deciding what Tab should do when the panel is open without a selection.
Usually, when there is a pre-selected result, Tab moves through results. Making it select the first result in the bug case would be coherent with that.
But that means to reach the page action buttons one must first close the results panel.

Summing up, supposing one wants to reach page action buttons, on Windows one can always use F6 and Tab.
Alternatively, today they can CTRL+L and Tab.

But if we make Tab coherently move through results, then they have to CTRL+L, ESC to close the panel, then Tab.

This is really an accessibility question, and the direction of this bug will depend on the accessibility answer.

please check my question in comment 9

(In reply to Marco Bonardo [:mak] from comment #9)

This is due to the fact CTRL+L now opens the Address Bar panel on Top Sites.
Tab is then captured by the panel itself.

This isn't supposed to be the case. Bug 1616880 (the successor to bug 1608766) changed this behaviour so that focusing the adress bar with the keyboard (alt+d, control+l) opens the panel, but tab shouldn't move through the results unless there's a search string.

The odd thing is that this behaves correctly if browser.toolbars.keyboard_navigation is set to true. It only breaks if it's set to false... and in a really weird way at that: the focus gets blurred when you press tab. I have no idea why.

7:02.62 INFO: Last good revision: 42b11b39afe4b668080000d177422a586e2dca44
7:02.62 INFO: First bad revision: 55d02702cb1088aad34f17d3c8dc6b85e8224e06
7:02.63 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=42b11b39afe4b668080000d177422a586e2dca44&tochange=55d02702cb1088aad34f17d3c8dc6b85e8224e06

That suggests bug 1654192 or bug 1680230. That seems odd - I can't see an obvious culprit - but I ran through mozregression a second time just to be sure and I got the same result. That also doesn't agree with Petr's assertion in comment 0 that this regression was introduced in Firefox 83, since those changes only landed in Firefox 85.

Thanks James, you are right, I totally forgot about Bug 1616880, and the fact we had already taken a decision about this matter.
I'll investigate how to fix the bug for keyboard_navigation = false.

This is the regression range I get, that is compatible with comment 7
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fad66448e049eb8fcebe1b56d172d3b1c61ed6e8&tochange=49ba9675c183ccbb6eb9e94a779e470709d0aef1

It just looks like it just never worked correctly with update2.

Heh, I should learn to read. I didn't see the regression range in comment 7. Still, I wonder why my regression range was so far off... twice!

https://hg.mozilla.org/mozilla-central/rev/9f5e51b38c2c

Backed out for causing frequent failures in Bug 1691389 and Bug 1652531.

TH link: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&fromchange=ed0ab9078607e373de6cc25ff31c28fc1c0e0120&tochange=6e5caabf4c1fc44de3afcb2ffa565127d40ebb28&searchStr=linux%2C18.04%2Cx64%2Cdebug%2Cmochitests%2Cwith%2Cfission%2Cenabled%2Ctest-linux1804-64%2Fdebug-mochitest-browser-chrome-fis-e10s%2Cbc10&selectedTaskRun=WtnJ9hSOQu-C8Fxg0qs1Ew.0

Failure logs:
https://treeherder.mozilla.org/logviewer?job_id=329221837&repo=autoland
https://treeherder.mozilla.org/logviewer?job_id=329239475&repo=autoland

Backout link: https://hg.mozilla.org/integration/autoland/rev/566f81bfa373512b41c1a47962e21a06078d7bf8

Testing a version that avoids handling the pref change if a window is closed:
https://treeherder.mozilla.org/jobs?repo=try&revision=310165584b022e5f406fbebbe331d6d245f130e1

Backout merged: https://hg.mozilla.org/mozilla-central/rev/566f81bfa373

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

I've managed to reproduce the issue with Fx85.0a1.
The issue is verified fixed using the latest Fx87.0a1 on Windows 10, Ubuntu 18 and macOS 10.13. After setting the browser.toolbars.keyboard_navigation to false, the focus is correctly moved to the search bar after hitting the tab key (while the address bar is selected).