I'd argue that if you are typing in a text box and hit tab, focus should go to the next text box as it does roughly everywhere else. That would mean that if you have the search box enabled, hitting tab in the address bar - no matter its state - should move focus to the search box. The fact that it does not irritates me every day.

I think this is not feasible anymore for all users. It was discussed at long, users coming from other browsers, plus our historical users, rely on tab moving through all the results. We also recently introduced tab-to-search, equivalent to other browsers features.
With bug 1608766 if the panel is closed tab moves to the next widget.
If the panel is open, we could maybe introduce an a11y pref to make tab move between one-offs and results, though it will have a cost, since it will introduce a disabled-by-default navigation mode that may not be well tested by normal QA operations, thus it may break subtly with time. Of course it will need a thorough automated test.

May I add a thought:

In regard to muscle memory I believe it's important to consider what other programs on the same platform would do. It's less important what FF would do in another widget or what a unique program, like Chrome, would do. Expectations source from using loads of other programs on a platform and from switching between them quickly. It's not helpful to observe unexpected behavior in the first place and then to consider: "oh, no, ah, yes, it's this FF app again. It's different here …"

So, yes, a switch would be nice. I would tend to have FF rather align to my other applications on my machine than it to behave peculiarly.

Hello!
I tried to make a prototype. Please check the attached video.
The behavior is very simple. When the user presses the tab key while the result panel is showing, move the focus to the one-off buttons, likewise, move the focus to the result panel when the one-off buttons have the focus. What do you think?
Or, do you think that we need more complex behavior? For example, in the video, the second result is “exactly”, when the user selects it, then types the tab key, “exactly” will be the search term for the one-off search, etc. Please let me know.

Of course, I add a preference that enables this feature.
Thank you very much for your opinion, Axel!

Very nice! Great video. 👍

I threw the patch to the try.
https://treeherder.mozilla.org/jobs?repo=try&revision=bd5b7f4ee8c1fc897f5cc3c566d638f32ce8ee22
Please download the runnable image from above if wants to try.
Then, please add browser.urlbar.tabToToggleOneOffsFocus pref as true.

One concern I have is this doesn't seem to take Tab-to-search into account, or better it will pretty much make it Down-to-search if the pref is flipped. Anyway if the pref is only used for a11y purposes I suppose that may not be a big deal, likely it should move under a accessibility.urlbar.* branch.
I'd suggest to write an Engineering Proposal to capture benefits and risks to help the team making a better decision.

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

One concern I have is this doesn't seem to take Tab-to-search into account, or better it will pretty much make it Down-to-search if the pref is flipped. Anyway if the pref is only used for a11y purposes I suppose that may not be a big deal, likely it should move under a accessibility.urlbar.* branch.
I'd suggest to write an Engineering Proposal to capture benefits and risks to help the team making a better decision.

Thank you very much!

Ah, indeed. That is, it seems that there are two ideas, I think.
The one idea is, if we can consider the Tab-to-search item as one of the results in the panel, we move the focus to the one-off buttons when pressing the Tab key, and select Tab-to-search item by the Arrow-down key. The consistency of the visual and the behavior of the key typing look not bad. But, Tab-to-search” will not be Tab-to-search.
The other one is, that we select Tab-to-search item by the Tab key, then move the focus to the one-off buttons by next Tab key. If we consider “Switching by Tab key is to switch the search engine”, it might be good. However, moving the focus to Tab-to-search item that looks like one of the results, then moving to one-off buttons, might be felt weird a bit, I think.

Anyway, as you said, I will try to write the proposal.

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates and 5 See Also bugs.
:daisuke, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Based on recent development, this new behavior is not compatible with our needs.
Today down and tab have different behaviors where tab moves to the next widget, but that may be in the result itself, for example some results have a dismiss and/or a learn more link. Tab will move to those widgets inside the result, and then to the next result.
Now we could make so once there's no more per-result widgets it jump to one-off instead of the next result, but once we implement bug 1041761 each result will have a button that will be reachable through tab.
For that, we cannot change the tab behavior as requested here.
We may want to evaluate alternatives to make shortcut buttons more easily accessible, maybe a separate search button on the toolbar (that directly enters search mode for a specific engine), or some other kind of view. We're happy to evaluate proposals on that matter.