Use Ctrl-P/N to move up/down in the urlbar dropdown menu on Linux
Categories
(Firefox :: Address Bar, enhancement, P3)
Tracking
()
People
(Reporter: lilydjwg, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: blocked-ux)
+++ This bug was initially created as a clone of Bug #1813517 +++
With the newly enabled result menu it takes an extra tab to skip a history entry (and perhaps more in the future). Arrow keys can move up/down but they are less efficient because they usually require the user to move the whole right hand to reach.
It's traditional to use Ctrl-P/N to move / up in Emacs and command-line tools like bash etc. In Firefox urlbar, they currently invoke print or new window which doesn't make much sense here. I've heard they already work so on MacOS. So it'd be a good addition to support this on Linux too. (Maybe also on Windows? I'm not sure what Windows users expect for Ctrl-P/N.)
|
||
Comment 1•1 year ago
|
||
I think it makes sense, the only thing to decide is whether it's worth adding a pref.
Likely if we'd add a pref we could then just set a different default on the platforms, that sounds easy.
|
||
Comment 2•1 year ago
|
||
(In reply to lilydjwg from comment #0)
It's traditional to use Ctrl-P/N to move / up in Emacs and command-line tools like bash etc. In Firefox urlbar, they currently invoke print or new window which doesn't make much sense here.
These shortcuts generally work regardless of what's focused. We've discussed this yesterday, and I'm concerned that the number of users who might for instance want to open a new window while looking at address bar results could easily be larger than the number of users familiar with emacs commands. In other words, there's a good chance that implementing this would confuse or annoy more people than it would help.
I've heard they already work so on MacOS.
macOS uses Cmd+P and Cmd+N for Print and New Window, so it doesn't have the same constraints here.
|
||
Comment 3•1 year ago
|
||
I have a keyboard without arrow keys on the base layer, so I'm very used to navigating urlbar results with tab/shift+tab. It's also a gesture QWERTY users can do with only their left hand. I will add some hotkeys that work for me, but that capability is not so easy to access for most users. Ctrl+P/Ctrl+N are not the best either as they require use of the right hand for QWERTY. And require modifier keys of course. I can't think of any alternative to the Tab key. There aren't any other available non-printing keys on the left half of the QWERTY layout.
IMO, if a pref were to be added to enable Ctrl+P/Ctrl+N shortcuts, it would actually be better if the pref just made the menu buttons un-tabbable. Like, if we're going so far as to add a pref, might as well get the most mileage for it, and I'd imagine many more users are accustomed to using the Tab key than are accustomed to emacs hotkeys. Relatedly, it seems like the menu buttons should be accessible by ArrowLeft/ArrowRight, but right now they don't seem to be, at least for me on Windows 10. So if we made those buttons untabbable (either by pref or by default), they would not be keyboard accessible at all.
For me, it seems odd to require Arrow keys to navigate just urlbar results, but require Tab to reach the menu buttons. Since the urlbar results are going to be used far more frequently than the menu buttons. And the Tab key is much easier for most users to reach than the Arrow keys. It seems like the reverse would make more sense. Use Tab or ArrowUp/ArrowDown to navigate urlbar results, and use ArrowLeft/ArrowRight to navigate menu buttons. Though I can see the logic in letting Tab access all of the interactive elements in the urlbar results, I think we should at least let ArrowLeft/ArrowRight access the menu buttons.
|
|
||
Comment 4•1 year ago
|
||
The left and right arrow keys move the cursor in the address bar's input field. We'll have to maintain that behavior.
|
|
||
Comment 5•1 year ago
|
||
Ugh, sorry lol. Completely slipped my mind. I think Alt+ArrowUp/ArrowDown currently navigates one-off search modes. If it doesn't do anything OS-specific, making it navigate urlbar results and menu buttons might be a useful option for some. It's not a good replacement for the Tab key, but it preserves keyboard accessibility for users who try to remove the menu buttons or change the Tab behavior with userchrome/js/autohotkey/etc.
|
|
||
Comment 6•1 year ago
•
|
||
We would like to remove the ALT+UP/DOWN magic anyway, because it's undiscoverable and not a standard anyone would expect (we'll provide other ways to access the shortcut buttons). A lot of users cannot discover those shortcuts and thus it's not a good solution.
That also doesn't seem to help with the wish to navigate without moving the hands out of the keyboard left side.
I'd prefer we provide a good alternative for users who prefer to not move hands to the cursor buttons area, rather than hacking around ways to allow hiding the button through unsupported methods like userchrome (that is likely to create other issues, plus with the increase of buttons in results it won't be a stable solution).
The problem is that a standard in the market for that doesn't seem to exist.
That is not limited to Web Browsers, users are looking for a solution to that from many years, and the common accepted solution is using external tools to remap keys on a personal preference. This is a quite common task for developers, where they redefine ALT + IJKL/HJKL/WASD as alternative arrow keys. Since it may be common to do that for other software, it'd be fine to also use that in a Web Browser. And maybe that's the only real solution that is fully customizable per each user.
|
|
||
Comment 7•1 year ago
•
|
||
Considering the discussion here, we don't have many options to fix this problem.
Ctrl+p/n is something we can only leverage on the Mac.
Introducing other custom remaps of the arrow keys would be very complicate, due to the many layouts and personal preferences around.
Left/right, or any button that has control over the input field, can't be used to move focus.
In bug 1813517 we are introducing an about:config pref to disable tab keyboard navigation to the buttons, that can be used as a workaround to retain the existing tab behavior.
For any other cases, I think the best solution remains what users did with other software (I'm looking at text editors and browsers here), by using a third party software to have secondary arrow keys through ALT + (other keys), for example WASD, IJKL, HJKL are common choices. That allows everyone to customize their preferred combo, rather than us picking for them.
While UX continues investigating the best approach to navigate urlbar results, I feel like bug 1813517 for now is our best bet, and we should wontfix this.
Yes, I'm quite satisfied with the solution in bug 1813517. I don't have problems with a pref as long as it stays.
Description
•