1753878 - Add a setting to alleviate the Accel/Alt inconsistency between mouse/keyboard urlbar shortcuts

Status: NEW

(Firefox :: Address Bar, enhancement, P3)

Description

[Shane Hughes [:aminomancer]]

If you check the keyboard shortcuts SUMO page you can see how urlbar/searchbar shortcuts might be kinda confusing for new users. Everything uses Ctrl+Enter to open things in new tabs except the urlbar. There's also an undocumented inconsistency between the keyboard and mouse behavior, because the article doesn't list mouse commands. Because of the ctrlCanonizesURLs feature, we can't use Accel+Enter (or Accel+Shift+Enter) to modify where URLs/searches open. But we do use Accel+Left click.

So because Ctrl isn't available, Firefox has to use Alt+Enter to open results in a new tab. But since the equivalent mouse shortcut is Accel+click, this creates an inconsistency between mouse and keyboard behavior, which is potentially an accessibility issue. And it's made more impactful because it's not documented, or at least not in an obvious place afaik.

It's possible to get used to this, but it would be better to not have to. It seems like at the time canonization was added, shortcuts worked quite differently so this issue emerged after the fact.

There are several ways to approach this without changing the default behavior. I can think of 3 tentative ideas:

1. When the ctrlCanonizesURLs pref is disabled, swap the Alt+Enter shortcuts to Accel+Enter shortcuts. That is, modifier = ctrlCanonizesURLs ? Alt : Accel
2. Add a pref that makes the canonize modifier Alt instead of Ctrl
3. Change the canonization pref to an integer type; let user choose the modifier and then transform the _whereToOpen modifiers accordingly; migrate the old pref value to the new pref in some way

Either way we do this, though, imo the click and Enter modifiers should be the same. If we don't change the default behavior, users won't notice the above changes. It would make sense to at least experimentally try changing the default behavior on Nightly or something.

I think Ctrl is more sensible as a where modifier than Alt. Do we have any user data about how often canonization is used? I don't see any telemetry for it currently. I would expect Ctrl+Enter to work here the same way Ctrl+click does; and by default, I would expect Ctrl+click to work the same way on a urlbar result as it does on a link. So ideally, canonization would just be moved to altCanonizesURLs.

But otherwise, if we go with option 1 or 2, then for the default state, it would make sense for Alt+click to do the same thing as Alt+Enter.

If we go with option 3, then we can set the default value to the Alt key. But that still leaves room for the user to set it to something else. If they wanna use Shift key, it's easy enough to swap the Shift key's behavior (where = "window") to Alt. That is, whichever key the user chooses for canonization would end up swapping with Alt.

Even in the searchbar where canonization does nothing, we currently use Alt+Enter and Ctrl+click to open in a tab, instead of Ctrl+Enter and Ctrl+click. I would suggest we do the latter instead but make it affected by the pref, so the searchbar will behave in the same way as the urlbar.

I submitted a patch that will make this easier to change. All the urlbar/searchbar methods that care about Alt/Accel/Shift have been refactored to use this _whereToOpen method, that can transform its values based on prefs. So we can implement the same behavior in both searchbar and urlbar, to preserve the consistency between the two.

So just as an example, say user changes the canonization modifier pref from Alt (default) to Shift. Now if you use the Shift modifier in the urlbar it'll no longer open a new window, it'll canonize the search string. You'll have to use Alt to open a new window. In the searchbar there is no canonization, so this would mean Shift+Enter is the same as Enter; and Alt+Enter opens the search in a new window.

It's a lot easier to do that with the aforementioned patch. But I wanted to get some feedback first anyway because there are a lot of different ways to approach this.

Comment 1

[Shane Hughes [:aminomancer]]

Btw, I've noticed there's another layer to this as well. It would be reasonable for a user to see Accel+click as being a kind of functional alias for middle click. On macOS I think in many cases they yield the same behavior, and elsewhere in Firefox they do as well — including in the urlbar and searchbar. At least with respect to links, urlbar results, and searchbar results, Accel+click does the same thing as middle click. So if middle click does something, we often expect Accel+click to do the same.

Similarly, with respect to links, urlbar results, and searchbar results (and a huge number of form elements in Firefox, and probably the majority of GUI controls in history), Enter does the same thing as left click. So there's a vastly stronger semantic relationship between Accel+click and Accel+Enter than there is between Accel+click and Alt+Enter. In other words,

1. Middle click should open a result in a new tab, because that's what it does with links and most users are really used to that I expect.
2. If middle click opens a result in a new tab, then Accel+click should (and does).
3. If unmodified Enter and unmodified click do the same thing, then...
4. Accel+Enter should do the same thing as Accel+click.
5. Therefore, Accel+Enter should open a result in a new tab.

And in comparison, Alt just doesn't seem to have any relation to any of this. It's probably the last modifier I'd expect to open a new tab.

So the present situation creates a usability problem because it requires the user to think. They're probably expecting Accel+Enter to do the same thing as Accel+click. And then when they see that it doesn't, they're either giving up (and just opening a new tab via Ctrl+T) or they're investing time: either in looking up the shortcuts (and they won't find mouse shortcuts on a SUMO page afaik) or in blind trial & error.

Even after having worked with it for a while and somewhat gotten used to it, I feel an increased sense of cognitive load when trying to use the keyboard shortcuts. I know consciously that Alt+Enter is the shortcut, but I can't shake my ingrained expectation that Enter and click do the same thing. I involuntarily conflate them. So almost every time I use it in testing, I wind up accidentally using the wrong command. Takes me a couple tries.

Which is a big problem if you're using this shortcut to avoid navigating away from your current page. Maybe you have important form information entered in the active page, and you need to search something. If you type into the address bar and hit Ctrl+Enter, expecting it to open a new tab, you may have just lost all your form data. With such a high risk, it makes sense why I almost never use these shortcuts, opting instead for Ctrl+T => type => Enter.

That doesn't seem like an optimal new user experience either, so I believe the ideal solution here is to change the default behavior. Not only should the modifier be the same for mouse & keyboard events, but that modifier should be Accel, hands down. Which means canonization has to be tied to some other key, and it seems like Alt is the best option for that. I think that might surprise some users who got used to the inconsistency, but idk how many people use canonization.