1949999 - evaluate how to better harmonize key modifiers in browser an content (Cmd+Enter in MacOS address bar canonizes, Alt+Enter opens in new tab)

Status: NEW

(Firefox :: Address Bar, defect, P3)

Description

[Jan Moesen]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:137.0) Gecko/20100101 Firefox/137.0

Steps to reproduce:

Bug 1945422 changed the behaviour of Cmd+Enter on macOS. When pressing Cmd+Enter in the address bar, Firefox used to open the URL or search query in a new tab. Now it opens it in the current tab.

Option/Alt+Enter still works, but (warning: anecdata) I specifically untrained myself from using Option/Alt+Enter because of consistency: pressing Cmd while clicking a link with the mouse opens that link in a new tab. Pressing Option/Alt while clicking a link saves the linked page to disk, so it made sense to learn that “Cmd+something” == “new tab” while “Alt+something” == “save”. I’m guessing this is not enough of an argument for changing the behaviour back, though. Would be interesting to see data on using Cmd+Enter to “auto-www-dot-com” a string versus opening a URL in a new tab, if such data are available.

STR:

1. Focus the address bar. The current URL is fine.
2. Press Cmd+Enter.

Actual results:

→ URL gets loaded in current tab.

Expected results:

→ URL should open in a new tab.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

:mak, since you are the author of the regressor, bug 1945422, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Jan-Erik Rediger [:janerik]]

Ran into that too.
A workaround is to set browser.urlbar.ctrlCanonizesURLs to false, disabling the canonization feature. This makes cmd+enter work again to open urls in a new tab.

Comment 4

[Marco Bonardo [:mak]]

ALT+Enter is the official urlbar shortcut to open in new tabs, as historically cmd+enter was already assigned to canonization, it was later changed to CTRL+Enter to unify behavior with other platforms, unfortunately MacOS broke our plan.
We know it's not consistent with content cmd+click, but there's a limited number of available modifiers and combo.

As Jan suggested you can disable canonization if you prefer to use CMD differently, there's a pref for it.

We'll evaluate long term if there's a chance to better uniform modifiers across browser and content. Though for now it's a problem.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 9

[Will]

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

ALT+Enter is the official urlbar shortcut to open in new tabs, as historically cmd+enter was already assigned to canonization, it was later changed to CTRL+Enter to unify behavior with other platforms, unfortunately MacOS broke our plan.
We know it's not consistent with content cmd+click, but there's a limited number of available modifiers and combo.

As Jan suggested you can disable canonization if you prefer to use CMD differently, there's a pref for it.

We'll evaluate long term if there's a chance to better uniform modifiers across browser and content. Though for now it's a problem.

I'm not sure if this would be considered an option or not, but could the solution be to have users turn off the CTRL+Enter shortcut at the MacOS level if they want the canonization shortcut? This would still allow CTRL-Enter for canonization and continue the long held mapping for CMD-Enter for opening in a new tab.

I guess I view it as two sets of users, both of them possibly losing their default behavior. If you keep CMD-Enter as new tab, then no one has to relearn a shortcut, but the canonization group has to uncheck an OS feature box but NOT relearn any shortcuts. If you decide to change canonization to CMD+Enter, then BOTH groups have to relearn a new shortcut.

To turn off the OS level CTRL+Enter is a simple check-box in System Settings (System Settings->Keyboard->Keyboard Shortcuts->Keyboard->Show contextual menu), but again, not sure if this would be a viable option to choose.

Comment 10

[Marco Bonardo [:mak]]

(In reply to Will from comment #9)

I'm not sure if this would be considered an option or not, but could the solution be to have users turn off the CTRL+Enter shortcut at the MacOS level if they want the canonization shortcut? This would still allow CTRL-Enter for canonization and continue the long held mapping for CMD-Enter for opening in a new tab.

The new Ctrl+Enter on Mac is an accessibility feature that we think is important, as it's finally fixing the lack of a context menu shortcut on the Mac. So we'd not suggest users to disable it just to get another feature working.

Comment 16

[waynejwoww]

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

ALT+Enter is the official urlbar shortcut to open in new tabs, as historically cmd+enter was already assigned to canonization, it was later changed to CTRL+Enter to unify behavior with other platforms, unfortunately MacOS broke our plan.
We know it's not consistent with content cmd+click, but there's a limited number of available modifiers and combo.

As Jan suggested you can disable canonization if you prefer to use CMD differently, there's a pref for it.

We'll evaluate long term if there's a chance to better uniform modifiers across browser and content. Though for now it's a problem.

i do not want to sound rude or sarcastic, but here are again my honest thoughts that hopefully will help you with the decision:

it is not 1998 anymore. a lot of websites do not use ".com" as tld anymore. firefox is a globally used product. the prevalence of ".com"-addresses differs vastly from region to region. a prominent shortcut like ctrl+enter should not be occupied by such an outdated and mostly regionally usable feature.

autocompletion-suggestions (canonization) are triggered anyways by merely starting typing, so in most cases the address will be completed to .com anyways and subsuequently can be opened by just hitting enter (without the need of any modifier).

Comment 17

[waynejwoww]

that being said, if you were considering moving "open in a new tab" to [alt]+[enter] in order to allow mac users to have a shortcut to "open in new tab" too, just throw away canonization completely and make [ctrl/cmd]+[enter] AND [alt]+[enter] open a new tab.

imho a linux/windows user should not suffer because of mac os.

Comment 19

[Mark]

I just wanted to throw in my 2¢ here. As a very long-term Firefox user who relies on it as my primary browser, this is a very, very frustrating change. Never in my 20 years of web browsing have I wished for a canonization feature and having it displace one of the top 5 shortcuts I use in daily browsing is very frustrating. Along with cmd-l for jumping to the URL, cmd-w for closing tabs and ctrl-tab for swapping between recent tabs, there nothing I use as more than cmd-enter for opening new tabs.

This new behavior of canonization has been frustrating repeatedly throughout the day for multiple days and has wasted a lot of valuable time and driven me back to using Brave as my primary browser. I don't even really understand the purpose of the canonization feature or how it helps users at all from a productivity standpoint, let alone why it was deemed so important as to displace "open new tab". There are probably millions of others in a similar situation who are equally frustrated by hijacking the commonly used shortcut for opening new tabs who just haven't bothered to create a bugzilla account and share the experience.

Do with this product feedback what you will, and good luck.

Comment 20

[Marco Bonardo [:mak]]

(In reply to Mark from comment #19)

I just wanted to throw in my 2¢ here. As a very long-term Firefox user who relies on it as my primary browser, this is a very, very frustrating change.

Thank you for your honest feedback. That's understandable, and the reason why we put a Release Note explaining the reason behind the change and the preference to revert the behavior to the previous one.

Long term we'll look into making these shortcuts more coherent and more easily modifiable.