Closed Bug 1608766 Opened 4 years ago Closed 4 years ago

openViewOnFocus breaks most common pattern for quickly navigating toolbars with the keyboard

Categories

(Firefox :: Address Bar, defect, P2)

Product:
Firefox
Component:
Address Bar
Type:
defect
Points:
3

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 74
Iteration:
74.2 - Jan 20 - Feb 09
Tracking Flags:
Tracking Status
firefox-esr68 --- unaffected
firefox72 --- unaffected
firefox73 --- wontfix
firefox74 + verified

People

(Reporter: Jamie, Assigned: bugzilla)

References

(Regression)

Details

(Keywords: access, regression, Whiteboard: [access-p1])

Attachments

(1 file)

Bug 1608766 - Disable tabbing through results after focusing the Urlbar with the keyboard, behind a pref. r?mak
47 bytes, text/x-phabricator-request
Details | Review

Bug 1603778 enabled browser.urlbar.openViewOnFocus by default in Nightly. Unfortunately, this breaks the most common (and officially documented on Mozilla support) pattern for quickly navigating toolbars with the keyboard:

  1. Users press alt+d or control+l.
  2. They would then generally press tab or shift+tab to begin navigating to other toolbar controls.

With openViewOnFocus enabled, pressing tab or shift+tab (step 2) moves through address bar suggestions instead of moving to the next or previous toolbar control.

The tricky issue here is that this behaviour appears to be by design. I don't know what the product goal is, but we clearly want users to see the suggestion list when they focus the address bar. If that's what we want for mouse users, it follows that it's also what we want for keyboard users... but currently, that's in direct conflict with toolbar keyboard navigation.

There are three possible solutions:

  1. Don't do openViewOnFocus for keyboard users. But that means keyboard users get a different UX.
  2. Stop tab/shift+tab from navigating suggestions, either always or only if openViewOnFocus triggered. There's bug 1437524 for getting rid of this always, but there's a lot of controversy concerning that.
  3. Add another keystroke to focus the toolbar for quick toolbar keyboard navigation which doesn't trigger openViewOnFocus. That means we have to come up with yet another keyboard command and means users have to re-train something they do reflexively (and potentially hundreds/thousands of times a day).

I vote for option 2. Using tab to navigate a list is clearly an antipattern that goes against all commonly accepted keyboard navigation standards. And the suggestions are, for all intents and purposes, a list.

As you know, the problem with removing results navigation through TAB is that it's supported by other browsers (Chrome and now Edge Beta), it may not be trivial to change it, because even if Firefox usage of that feature is really low according to telemetry, we may not want to break incoming users expectations.

I'm not sure what to suggest here, maybe we should just disable openViewOnFocus behavior if a screen reader is in use.

Blocks: urlbar-update-1
Priority: -- → P2

This does not just affect screen reader users, but all keyboard power users who have started taking advantage of the better keyboard navigation introduced in Firefox 67 and updated in 70.

Ctrl+K/J (focus search bar) has had the same behavior for some time.

Press ESC to exit the view and then press Tab or use F6 instead which still works without opening the view.

Problem is that that is a thousand extra keystrokes per day if you consider how often keyboard users may want to do this. This is not a mere inconvenience. This is a significant productivity killer.

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

As you know, the problem with removing results navigation through TAB is that it's supported by other browsers (Chrome and now Edge Beta), it may not be trivial to change it, because even if Firefox usage of that feature is really low according to telemetry, we may not want to break incoming users expectations.

I'm not fond of this argument, especially since we've got a plethora of alternative keyboard navigation methods available. If we have a genuine case for removing tab-navigation for the Awesomebar results list, then we should consider it.
(Disclaimer: I haven't read through all the comments in bug 1437524 yet.)

(In reply to Kestrel from comment #4)

Ctrl+K/J (focus search bar) has had the same behavior for some time.

Sure, except that's not something people commonly rely on for toolbar keyboard navigation.

Press ESC to exit the view and then press Tab or use F6 instead which still works without opening the view.

Aside from the efficiency argument already made in comment 5, it's also potentially very confusing for users, especially screen reader users. When a user focuses a control and presses tab, they expect to move to the next focused control. They don't expect to have to think about whether an autocomplete appeared before they hit tab, especially because they didn't type any text. For screen reader users, it's even worse because the fact that the autocomplete expanded isn't as immediately obvious. That said, I don't want this latter point to be used as an argument for a screen reader specific workaround as suggested in comment 2; this affects all keyboard-heavy users, regardless of whether they use a screen reader. It's also worth noting that screen reader specific workarounds are generally very brittle; screen reader detection is far from perfectly reliable on several operating systems.

To put this another way, imagine that a modal dialog appeared whenever you moused over the address bar and you had to actively dismiss it in order to continue interaction. That's essentially what this is like for keyboard users trying to navigate the toolbar. "Just press escape" is not an acceptable solution for something that users do reflexively up to hundreds or thousands of times a day, let alone a pattern that is officially documented as the recommended pattern by Mozilla.

F6 does work without opening the view, but that's still significant re-training for such a reflexive action. Moreover, f6 can hit other areas (e.g. sidebar, pop-ups), so it doesn't always provide immediate access to the toolbar.

Another argument against F6: Unlike CTRL+L or Alt+D, F6 requres the hand travel far away from the home row, and thus takes longer to execute. Especially for typists who use all fingers to type, this is a significant interruption of the normal flow.

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

As you know, the problem with removing results navigation through TAB is that it's supported by other browsers (Chrome and now Edge Beta), it may not be trivial to change it, because even if Firefox usage of that feature is really low according to telemetry, we may not want to break incoming users expectations.

What about ignoring tab/shift+tab for just the case where openViewOnFocus triggers and the user presses tab/shift+tab without typing any text or pressing up/down arrow? That will probably require some tricky state management, but it should be possible. That fixes the issue here without disabling openViewOnFocus and without disabling tab altogether (as proposed in bug 1437524). I don't think this solution breaks any incoming user expectations: you can't press alt+d/control+l and then tab in Chrome to select the first result.

+1 to that proposal.

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

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

As you know, the problem with removing results navigation through TAB is that it's supported by other browsers (Chrome and now Edge Beta), it may not be trivial to change it, because even if Firefox usage of that feature is really low according to telemetry, we may not want to break incoming users expectations.

What about ignoring tab/shift+tab for just the case where openViewOnFocus triggers and the user presses tab/shift+tab without typing any text or pressing up/down arrow? That will probably require some tricky state management, but it should be possible. That fixes the issue here without disabling openViewOnFocus and without disabling tab altogether (as proposed in bug 1437524). I don't think this solution breaks any incoming user expectations: you can't press alt+d/control+l and then tab in Chrome to select the first result.

Making Tab not select autocomplete items at all seems preferable to be in terms of internal consistency.

(In reply to Dão Gottwald [::dao] from comment #12)

Making Tab not select autocomplete items at all seems preferable to be in terms of internal consistency.

Perhaps, but there also seems to be a lot of resistance to that change and this issue needs to get fixed before openViewOnFocus ships. Also, while it's more internally consistent, I'd argue it's not a consistency issue from a UX perspective: I wouldn't imagine a user would normally press tab to select an autocomplete suggestion unless they'd typed something first. If anything, it's inconsistent UX to have tab do something other than move focus to the next control in this interaction.

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

(In reply to Dão Gottwald [::dao] from comment #12)

Making Tab not select autocomplete items at all seems preferable to be in terms of internal consistency.

Perhaps, but there also seems to be a lot of resistance to that change [...]

I don't think we've established that. mak is understandably careful about dropping ancient behavior that's also supported by Chrome but that doesn't mean we can't do it, especially since telemetry tells us that this isn't used a lot.

Also, while it's more internally consistent, I'd argue it's not a consistency issue from a UX perspective: I wouldn't imagine a user would normally press tab to select an autocomplete suggestion unless they'd typed something first. If anything, it's inconsistent UX to have tab do something other than move focus to the next control in this interaction.

No, that doesn't make much sense to me. From the perspective of a user who doesn't use Tab to focus other toolbar items, it's unclear why typing something would make a difference for how you can reach autocomplete items.

(In reply to Dão Gottwald [::dao] from comment #14)

No, that doesn't make much sense to me. From the perspective of a user who doesn't use Tab to focus other toolbar items,

It's not just toolbar items. You use tab to focus other controls period.

it's unclear why typing something would make a difference for how you can reach autocomplete items.

As I understand it, the idea of tab autocompleting comes from shells and the like where you type some text and hit tab to autocomplete, where typing text is a prerequisite for this behaviour. If it weren't for that, I'd argue pressing tab to autocomplete makes no sense at all.

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

(In reply to Dão Gottwald [::dao] from comment #14)

No, that doesn't make much sense to me. From the perspective of a user who doesn't use Tab to focus other toolbar items,

It's not just toolbar items. You use tab to focus other controls period.

I'm not sure what you're saying. Sure there are users that want to tab to other controls in the toolbar. There are also other users who don't do that yet may want to select autocomplete items with the keyboard. I for one am such a user and would prefer Tab not to do different things depending on whether I typed something.

To be clear, I'm all in favour of removing TAB going through results, it's just the last time I proposed to do it, product management didn't want to, because of lack of impact data, users onboarding from other browsers, and a Mozilla internal vocal minority. That's why I added the telemetry probe to measure how much that selection method was used.
Current data from FX_URLBAR_SELECTED_RESULT_METHOD tells that tabEnterSelection is:

  • 0,06% in Beta
  • 0,19% in Nightly

(In reply to Dão Gottwald [::dao] from comment #16)

I'm not sure what you're saying. Sure there are users that want to tab to other controls in the toolbar.

I'm saying that outside of document editors, tab is well defined as a keystroke which moves to the next focusable control. The only cases where I've ever seen tab do autocompletion (outside of Firefox) are when you've typed something and hit tab to autocomplete it.

At the end of the day, my intent was to provide a solution which balanced the "tab must autocomplete" side with the openViewOnFocus requirement. I don't personally mind which way we go here. I must stress, however, that from an a11y perspective, this cannot ship as is.

Blocks: 1606920
Points: --- → 3

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

product management didn't want to, because of [...] users onboarding from other browsers, and a Mozilla internal vocal minority.

I was thinking that this might be a good use of the Tip result beyond Interventions and Search Tips. The first couple of times a user tries to TAB through results, we could show a Tip result saying that we recommend they use the down arrow since we no longer support TABing through results. This is just a rough idea: the interaction would ofc need some work from UX/Product.

I extracted some telemetry numbers from the 1st of December and version >= 69.0: 0.04% of result selections were through tab, 0.54% of users selected with tab at least once. In Nightly I see a 0.08% of tab interactions, and 1.75% of users doing it at least once. Take the numbers with a grain of salt, I had to use BigQuery because the telemetry dashboard is broken, but they seem consistent with what I saw on the dashboard earlier.

Verdi and a11y suggest we should disable tab results navigation when the interaction starts from the keyboard shortcut, so we preserve the behavior for mouse users.
But Dao has valid points about avoiding code complication just to serve what seems to be a barely used case, and that we don't know if tab users are more likely to start interaction with mouse or keyboard.

Taking the partial disabling path, we could monitor telemetry; if it drops drastically it means most tab users started interactions from the keyboard, then we broke most tab users. At that point we'd need either to reintroduce it somehow, or completely remove it because at that point the benefit is even smaller.
To be on the safe side I still suggest going the pref way, clearly this doesn't clear our threshold for users benefit, but it's an historical behavior and a non-trivial amount of users seem to use it at least once.

Assignee: nobody → htwyford
Status: NEW → ASSIGNED
Iteration: --- → 74.2 - Jan 20 - Feb 09
Pushed by htwyford@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/431954324f6b
Disable tabbing through results after focusing the Urlbar with the keyboard, behind a pref. r=mak

https://hg.mozilla.org/mozilla-central/rev/431954324f6b

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox74: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 74
Regressions: 1613907

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

To put this another way, imagine that a modal dialog appeared whenever you moused over the address bar and you had to actively dismiss it in order to continue interaction. That's essentially what this is like for keyboard users trying to navigate the toolbar. "Just press escape" is not an acceptable solution for something that users do reflexively up to hundreds or thousands of times a day, let alone a pattern that is officially documented as the recommended pattern by Mozilla.

I think we have different navigation flows. If I type text in the awesomebar, I want to look through results in the awesomebar and quickly navigate them. I've never once wanted to keyboard over to bookmarks (I can also get to those through the awesomebar).

This change feels really painful after 10+ years of using the existing behavior, but if I do have to retrain my brain, what are the alternative shortcuts where I can stay on the home row? I couldn't find anything on https://developer.mozilla.org/en-US/docs/Tools/Keyboard_shortcuts

(In reply to Brendan Dahl [:bdahl] from comment #24)

This change feels really painful after 10+ years of using the existing behavior, but if I do have to retrain my brain, what are the alternative shortcuts where I can stay on the home row? I couldn't find anything on https://developer.mozilla.org/en-US/docs/Tools/Keyboard_shortcuts

I'm in the same situation and AFAIK there's no alternative shortcut that doesn't need you to leave the home row. Currently, the only keyboard keys that work to browse the list are the arrow keys.

(In reply to Brendan Dahl [:bdahl] from comment #24)

If I type text in the awesomebar, I want to look through results in the awesomebar and quickly navigate them.

The key point here is "type text in the awesomebar". That's why I suggested comment 10; i.e. tab still navigates results if you press alt+d/control+l and then type text, but doesn't if you press alt+d/control+l and type nothing. However, that idea was rejected in comment 12. I still think it would better fit what users seem to want here.

I've never once wanted to keyboard over to bookmarks (I can also get to those through the awesomebar).

It's not just keyboarding to bookmarks. It's about being able to access the toolbar at all with the keyboard. My guess is that you use the mouse for toolbar controls other than the address bar, but some users don't have that choice.

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

The key point here is "type text in the awesomebar". That's why I suggested comment 10; i.e. tab still navigates results if you press alt+d/control+l and then type text, but doesn't if you press alt+d/control+l and type nothing. However, that idea was rejected in comment 12. I still think it would better fit what users seem to want here.

From what I understand, the real issue with any alternative like comment 10 is that they aren't WCAG compliant. I mean I'd really like to keep the Tab behavior as is but I'm ok to loss it for the sake of making the app more accessible.

Personally, I think we should work on a more robust and global solution when it comes to the builtin keybind instead of fighting to keep the current behavior. By that I mean, we should work on a way to expose the binding to the users so they can modify them. If I'm not mistaken, there's already an issue for that but I can't remember the ID. This would resolve the current issue and many more like the one with ctrl+q (close window) and ctrl+w (open window) that are also very irritating on a qwerty keyboard.

Note that you can set pref browser.urlbar.update1.restrictTabAfterKeyboardFocus to false to disable the behaviour landed here.

See Also: → 1437524

Sorry, I think the old behavior is much better. It is lots easier for your hands to hit the Tab key to cycle through autocompletes than it is to use the down arrow key. Tab is easily pressed by the pinky finger, whereas you have to move your whole right hand to hit the down arrow. The down arrow key is also much smaller than Tab on most keyboards, especially MacBooks. I use the Tab key to cycle through autocompletes 20-30 times a day. I've NEVER wished Tab would send me to the toolbar buttons instead.

I've used Tab this way since I first started using Firefox back when it was still called Firebird. So this muscle memory is pretty ingrained at this point.

Also worth pointing out that Tab behaves this way in Chrome. (Meaning, Tab cycles through the autocompletes.... as expected.

Honestly not sure who wants Tab to jump to the toolbar buttons. How is that useful? I can see the argument for why that seems more "consistent" with how Tab behaves in other contexts, but I don't think it's worth throwing away 15 years of muscle memory.

Andrew, quoting Jamie from comment #26:

It's not just keyboarding to bookmarks. It's about being able to access the toolbar at all with the keyboard. My guess is that you use the mouse for toolbar controls other than the address bar, but some users don't have that choice.

In other words, if a person cannot use a mouse, maybe because they're blind, maybe because they have tremors that don't allow them the fine-grained control a pointing device requires, they have to be able to access all toolbar controls with the keyboard. The way things suddenly worked for us before this bug was fixed was that we had to hit escape before we could press tab to move to other toolbar controls.

And as Jamie points out in comment #28:

Note that you can set pref browser.urlbar.update1.restrictTabAfterKeyboardFocus to false to disable the behaviour landed here.

(In reply to Marco Zehe (:MarcoZ) from comment #30)

And as Jamie points out in comment #28:

Note that you can set pref browser.urlbar.update1.restrictTabAfterKeyboardFocus to false to disable the behaviour landed here.

Please don't rely on that pref to continue to work indefinitely.

I understand the accessibility angle- and it does make sense to me. But I think the percentage of users who currently use Tab "the old way" is a bigger number than the percentage of users who would prefer it behaves in this new way. (Obviously I don't know that for sure, not having access to the telemetry, but again... the current behavior is quite longstanding.)

And again, Chrome uses Tab for the autocompletes. Imagine a Chrome user testing out Firefox and discovering a UX interaction they do 20 times a day doesn't work in Firefox. And there's no preference in Settings to control it... they have to dig through Bugzilla and Reddit to figure out how to "fix" it. That's going to be a negative experience.

If the old behavior via "browser.urlbar.update1.restrictTabAfterKeyboardFocus" will 100%-for-sure be going away, then I as a user will be 100%-going-away.

I'd hope you decide to make the "new behavior" a configurable setting, but defaulting to off.

(In reply to Marco Zehe (:MarcoZ) from comment #30)

In other words, if a person cannot use a mouse, maybe because they're blind, maybe because they have tremors that don't allow them the fine-grained control a pointing device requires, they have to be able to access all toolbar controls with the keyboard. The way things suddenly worked for us before this bug was fixed was that we had to hit escape before we could press tab to move to other toolbar controls.

How do Chrome and Edge handle this case for tabbing to other toolbar controls?

If the user wants to select other toolbar controls, why are we making them first focus the urlbar? Perhaps a different keyboard shortcut could be used to focus the toolbar buttons instead of forcing the user to first focus the urlbar and then immediately tab away? That would reduce the number of steps for keyboard users without breaking urlbar result tabbing. Win/win! :)

I really miss tabbing through urlbar results. FWIW though, while Chrome and Edge support tabbing through urlbar results, Safari on macOS does not.f

Sorry to pile in here, but I would have expected the tab keystroke to work like the one in the separate search bar -- to select a one-off-search engine.

I can file a new bug around this, although I think I may have in the past (at the very least to make this consistent, because otherwise it feels sloppy).

(In reply to Chris Peterson [:cpeterson] from comment #33)

I really miss tabbing through urlbar results. FWIW though, while Chrome and Edge support tabbing through urlbar results, Safari on macOS does not.

I think that this is critical. Safari has much of an intentional design approach than does Chromium, and the tabbing through autocomplete suggestions has never made sense to me since it acts unlike other form controls anywhere on any OS.

I don't think it makes sense to follow bad decisions even if they are popular -- especially when telemetry says that a vast majority of people are not relying on this at all. I have opened bugs regarding copying good ideas from Chromium and other browsers, so the bar isn't "this will help migrate users from other browsers", but rather "this is better than what is in Firefox, so let's make Firefox better".

I agree that the new behavior "makes more sense". My problem is the stated intention to remove the config key to toggle the old behavior. Especially since I doubt this behavior is something that can be modified by WebExtensions.

While there may be a non-negligible number of users who will LIKE the new behavior, it's worth pointing out that there are several real people who care enough about the old behavior to comment in the bug. That's the Firefox community engaging with the developers directly. These (myself included) are real power users who will be alienated if the old behavior goes away. And again, the old behavior IS better for those people who don't need keyboard access to the toolbar icons. Tab is a lot easier to press than Down Arrow. That's not going to change.

It's totally possible to make this a win/win, but arbitrarily prioritizing one set of users needs over another set doesn't feel awesome.

See Also: → 57805

FWIW (and I think it is worth a lot), Windows, macOS and GTK all say that arrow keys ought to be used for lists:

Windows: https://docs.microsoft.com/en-us/previous-versions/windows/desktop/dnacc/guidelines-for-keyboard-user-interface-design
macOS: https://support.apple.com/en-us/HT204434
GTK: https://developer.gnome.org/hig/stable/keyboard-input.html.en

They also say to use Tab to move to the next control.

In this regard, Chromium (and old Firefox) is incorrect. I understand that people may think this is actually more usable, but for there to be a rule in various HIGs that is broken without a great reason (and minimal usage in the real world), I think you do a disservice to prefer to use consistent apps within their desktop environments.

(In reply to Asif Youssuff from comment #34)

I don't think it makes sense to follow bad decisions even if they are popular -- especially when telemetry says that a vast majority of people are not relying on this at all.

Neither we should ignore breaking a old behavior like Tab just because people using it are a minority. If we were thinking like that then Firefox wouldn't even be accessible to screen reader at all... I mean there's definitely better arguments than the telemetry one.

Anyway I'll say it again, I totally understand the decision and is even in favor for the new behavior to be the default but I think the about:config pref should be kept as long as bug 57805 isn't resolved. I think after 20 years we (user, devs) deserve a better way to handle keyboard shortcuts in Firefox. So, let's work together instead of fighting over which behavior should be kept or not.

(In reply to andrew from comment #32)

I understand the accessibility angle- and it does make sense to me. But I think the percentage of users who currently use Tab "the old way" is a bigger number than the percentage of users who would prefer it behaves in this new way.

That may be so, but this ability to tab out of the address bar has existed for a long time as well. See below.

And again, Chrome uses Tab for the autocompletes.

Sure, but only after you type some text. That is, if you press alt+d and then tab in Chrome, it does not autocomplete. The problem is that in Firefox, the address bar now opens when you press alt+d.

Imagine a Chrome user testing out Firefox and discovering a UX interaction they do 20 times a day doesn't work in Firefox.

If a Chrome user hits alt+d then immediately hits tab, they don't autocomplete. Which again is why I suggested comment 10 instead of what we have now.

(In reply to Danny Colin [:sdk] from comment #27)

From what I understand, the real issue with any alternative like comment 10 is that they aren't WCAG compliant.

Can you elaborate on why it isn't WCAG compliant?

(In reply to Asif Youssuff from comment #34)

Sorry to pile in here, but I would have expected the tab keystroke to work like the one in the separate search bar -- to select a one-off-search engine.

I can file a new bug around this, although I think I may have in the past (at the very least to make this consistent, because otherwise it feels sloppy).

Spawned bug 1614833 around this.

Depends on: 1614833

(In reply to Danny Colin [:sdk] from comment #37)

(In reply to Asif Youssuff from comment #34)

I don't think it makes sense to follow bad decisions even if they are popular -- especially when telemetry says that a vast majority of people are not relying on this at all.

Neither we should ignore breaking a old behavior like Tab just because people using it are a minority. If we were thinking like that then Firefox wouldn't even be accessible to screen reader at all... I mean there's definitely better arguments than the telemetry one.

I don't disagree with you and unless some new information appears, I will refrain from further comments to not clutter the bug.

To clarify, I feel that the behavior is incorrect, so the telemetry information is really only relevant because if it were in wide usage, I would see it as an ameliorating factor in terms of regressing functionality for real users -- the first assertion is a qualitative assessment, the second a quantitative one about the scope of effect.

I don't disagree that telemetry is not the be all end all, but I think it is instructive when you want to do something that is against the grain (per HIGs, in this case) to help understand how much positive benefit there is across the userbase. You may want to cater to those users for some other reason rather than number of users, but that decision is above my pay grade, as I am a volunteer with only a single patch under my belt.

Accessibility doesn't strike me as the same thing (catering to a minority), as we know that improving accessibility improves usability for everyone, not just the disabled. The tab shortcut itself can be seen as an accessibility feature for people who do not use mice or find them hard to use, so here it is a question of trade-offs, usability and platform consistency. Accessibility to me feels like less of a decision driven by usage, and more often based on qualitative judgements and considerations like consistency and the vast body of user research that predates this feature.

I definitely think it'd be nice to have customizable keyboard shortcuts, though, since it lets people do what they want instead of relying on good decisions by developers, or continuing support for features not used by many.

[Tracking Requested - why for this release]: It may be a good idea to put this in the release notes as suggested here: https://www.reddit.com/r/firefox/comments/f27xss/url_drop_down_results_tab_key_in_ff74_beta/fhdnb72/

tracking-firefox74: --- → ?

(In reply to andrew from comment #35)

I agree that the new behavior "makes more sense". My problem is the stated intention to remove the config key to toggle the old behavior. Especially since I doubt this behavior is something that can be modified by WebExtensions.

We/ I have not stated any such intention to remove the pref now or in the foreseeable future. Not relying on hidden prefs to dictate your daily workflow is good practice, imo, because it'll spare you the pain, grief and need to adapt when such a pref does disappear. In any product you use, be it Firefox or Winamp or other.
I hope, andrew, that there is more to Firefox than just this feature that you're currently missing; I'd feel quite sad if our only key differentiator from Chrome would be whether you can tab to a result when you focused the URLBar using a keyboard shortcut.

I have to point out that this is a bug tracker, used to track work. We very much appreciate fresh insights and new opinions, as they influence our backlog and roadmap, but discussions belong in a different forum. Thank you.

Flags: qe-verify+
QA Contact: cristian.comorasu

(In reply to Mike de Boer [:mikedeboer] from comment #6)

we've got a plethora of alternative keyboard navigation methods available.

For my own personal use, what keyboard-based methods are there other than arrow keys now?

(In reply to Lukas Waymann from comment #43)

(In reply to Mike de Boer [:mikedeboer] from comment #6)

we've got a plethora of alternative keyboard navigation methods available.

For my own personal use, what keyboard-based methods are there other than arrow keys now?

Other than Up and Down, there's PageUp / PageDown for moving through the list quickly, and Ctrl+p / Ctrl+n on Mac. "Plethora of alternative" is a bit of an exaggeration I guess...

(In reply to Dão Gottwald [::dao] from comment #44)

Other than Up and Down, there's PageUp / PageDown for moving through the list quickly, and Ctrl+p / Ctrl+n on Mac. "Plethora of alternative" is a bit of an exaggeration I guess...

Hm, PgUp/Down are at the same place on my keyboard (and most recent thinkpad :sad:). Would be nice to add Ctrl + p / Ctrl + n (or an other modifier) on Windows and Linux. Should I open a new issue for that or the UX team has already decided on that?

(In reply to Danny Colin [:sdk] from comment #45)

Would be nice to add Ctrl + p / Ctrl + n (or an other modifier) on Windows and Linux. Should I open a new issue for that or the UX team has already decided on that?

Those are Mac-specific keybindings that already have different functions on Windows and Linux, namely Print and New Window.

That's why I specified "or other modifier". For example, Alt + p / n isn't binding to a function on WIndows and Linux. Could be a good alternative that would satisfy both poweruser who wants an easily accessible keybind without living the homerow and others who wants the UI to be consistent across the app.

No longer depends on: 1614833
Regressions: 1614833

I would like Ctrl+n/Ctrl+p as well. Since we're in the business of breaking uncommon workflows, what's the telemetry data on New Window and Print? 😜

Joking aside, I agree that Alt+n/Alt+p could be an alternative.

(In reply to Danny Colin [:sdk] from comment #47)

That's why I specified "or other modifier". For example, Alt + p / n isn't binding to a function on WIndows and Linux.

Those likely open a menu from the menu bar in some locales, as you would expect from shortcuts using Alt.

I think we're generally not eager to introduce nonstandard and undiscoverable alternative shortcuts here. We encourage users to use the arrow keys which are the standard for autocomplete widgets.

Blocks: 1616880

(In reply to Asif Youssuff from comment #36)

FWIW (and I think it is worth a lot), Windows, macOS and GTK all say that arrow keys ought to be used for lists:

...

In this regard, Chromium (and old Firefox) is incorrect. I understand that people may think this is actually more usable, but for there to be a rule in various HIGs that is broken without a great reason (and minimal usage in the real world), I think you do a disservice to prefer to use consistent apps within their desktop environments.

I'm sorry for entering this discussion so suddenly, but I can't agree less with the last statement.

First of all - Tab is used for moving through list of items in other applications, such as text editor like VSCode or IDE's like... well, any of them. As long as you have some form of autocomplete enabled - Tab is the default way of navigating through the list of suggestions.

In most cases you can easily change this of course, but Tab is still a default and for a reason it's easier to press it rather than move you hand to the arrow keys, and if you are one of the people who have keyboard without an arrow block - Tab (or some other 'action' button) is your only choice, because you can't use your favourite <hjkl> movement keys.

Surely, the majority of users use arrow keys but neither that, nor the fact that there is any sort of OS accessibility guide should be a reason for such a change, unless it is an optional feature. I don't want to sound rude but I thing it is time for some people to realise that you should be building convenient tool, not an artefact for the International Bureau of Weights and Measures.

I also want to chime in to say that IMO the arrow keys are just really awkward to use vs the tab key.

When you have both of your hands on the keyboard in the typing position, it's super easy to hit tab, I barely even have to move my finger and I almost never mistakenly hit another key.

The arrow key on the other hand requires me to move my finger way down to the bottom right of the keyboard, and I often mistakenly hit the left or right arrow key instead of the down arrow key. Slower and more mistake prone.

This change is really killing my workflow. Please at least make it optional!

I can confirm this fix as it is directly related to bug 1616880.

Status: RESOLVED → VERIFIED
status-firefox74: fixed → verified
Flags: qe-verify+
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: