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

Steps to reproduce:

• have some entries in the history
• search for some of them to appear in the urlbar dropdown menu
• try to select the second history entry shown

Actual results:

An extra tab is needed to skip the first history entry due to the right round three-dot button.

Expected results:

One tab moves down one entry, no more. The button on the right can be skipped or reached by other means.

mozregression finds
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=809ead0307798a50c8e9a8fb968b6100f4200d66&tochange=d8d6b1c8320f676a65d4102bd887e6ded706417c

Oh I see in bug 1801298 you've fixed the case for arrow keys, but I prefer tab / shift-tab because they are easier to reach and more intuitive for us programmers. Please fix this case too.

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

I think this was the intended behavior, but I will open this issue as an enhancement and maybe one of our devs can take a look and might know if its intended behavior or an actual defect.

Setting Regressed by field after analyzing regression range found by mozregression in comment #0.

First, let me explain why the buttons: we are trying to make many of the features discoverable and usable, plus we have a lot of ideas to add value and options. We think giving more control to the user over their data and the results composition is a good thing.

Second, why change tab? We already have results with sub-buttons, like Firefox Suggest, Quick Actions, etc., that require a way to select sub widgets, or buttons inside a single result. We are also evaluating to concretize undiscoverable features like the possibility to override a switch-to-tab entry to reopen the page. All of these features require a way for the keyboard to reach the buttons, and the universal way to move through widgets and buttons is tab, everyone is already used to tab moving through buttons.
With the direction we are taking, and the will to preserve accessibility through the keyboard, it's just no more possible to support tab to move through results. Down and up will continue working as usual. We know it will be annoying for some users that are used to move with TAB, we pondered a lot over that and tried to find solutions, but didn't find something good enough for discoverability and accessibility.

My suggestion, for how much it may sound disappointing, is to get used to down and up, because:

• even if you can disable the buttons now, after we release the feature, the pref will go away
• you may hide things with CSS, but the number of things to hide will just grow with time, making it even more annoying

Of course, we're open listening to ideas, but "other means to reach the button" must be an industry standard, not a custom made up solution.

to get used to down and up

OK, I guess I'll stick to smaller keyboards like 60-key ones in the future. Arrow keys on normal keyboards require moving the whole hand which is very inefficient.

Of course, we're open listening to ideas, but "other means to reach the button" must be an industry standard, not a custom made up solution.

Would you like the idea to use Ctrl-P/N to move up and down? They are Emacs / bash keys, and the current behavior (print / new window) doesn't make much sense in the urlbar. (If the user could custom shortcut keys....)

(In reply to lilydjwg from comment #6)

Of course, we're open listening to ideas, but "other means to reach the button" must be an industry standard, not a custom made up solution.

Would you like the idea to use Ctrl-P/N to move up and down? They are Emacs / bash keys, and the current behavior (print / new window) doesn't make much sense in the urlbar. (If the user could custom shortcut keys....)

You know what, those already work on Mac, if you think it's worth having them on Linux feel free to file a bug for it, I think it's a possibility.

Thanks, I've filed bug 1814059 for it.

Re-opening this after a discussion in Slack came to the consensus that it could make sense to add an about:config setting to allow reverting to previous behavior in the urlbar results of tab key navigation moving directly from result to result without highlighting each result's submenu.

To summarize the points discussed:

• Navigating urlbar results with the tab key is much more convenient than using the arrow keys because it the tab key is easily reachable from the standard typing position while arrow keys are not, and some keyboards have less accessible arrow keys (e.g. Mac keyboards with half-size up/down arrow keys).
• Navigating urlbar results with the tab key is a long-supported feature that people have built muscle-memory around.
  • Suggestion to use/add telemetry to see how many people navigate urlbar results with the tab key vs arrow keys.
  • Chrome/Chromium browsers also allow navigating their urlbar results with the tab key.
• It's important for the urlbar results submenus to be keyboard accessible, and using keys other than the tab key isn't advisable/practical.
  • There is some industry precedent for this behavior, as in Chrome for urlbar results that can be removed using tab key navigation does go on to highlight the button to remove the result.
• To balance support for historical/ingrained behavior and accessibility it was agreed an about:config setting to exclude urlbar results submenus from tab key navigation could be a good compromise/escape hatch.

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

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

Testing this in Nightly 112.0a1 (2023-02-22), with browser.urlbar.resultMenu.keyboardAccessible set to false the result menu buttons are indeed skipped when navigating using the tab key, but when clicking on the result menu buttons with the mouse cursor the menu isn't shown.

(In reply to Sean Rose [:srose] from comment #15)

Testing this in Nightly 112.0a1 (2023-02-22), with browser.urlbar.resultMenu.keyboardAccessible set to false the result menu buttons are indeed skipped when navigating using the tab key, but when clicking on the result menu buttons with the mouse cursor the menu isn't shown.

Uh-oh. Filed bug 1818455.

Verified as fixed in our latest Nightly build 112.0a1 (2023-02-22). I will add myself to CC for the remaining issue.