1945422 - Ctrl+Enter keyboard shortcut in the address bar no longer adds "www." and ".com" to the address bar string on macOS

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[Chris Peterson [:cpeterson]]

[Tracking Requested - why for this release]:

This bug is a regression in Fx 136 from bug 1936928.

@ Emilio, I bisected this regression to this pushlog for your fix for focused element bug 1936928:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=870b0e5248c394c7606a55c939b064c6cdc46d4f&tochange=7290a2bc3b327fffed7abe4886a24057f935f73b

Steps to reproduce

1. On macOS, click to focus the address bar. (I'm using macOS 15.2 Sequoia)
2. Enter example in the address bar.
3. Press Ctrl + Enter.

Expected behavior

The address bar should expand example to https://www.example.com/ and navigate to the website.

Actual behavior

Ctrl + Enter opens the address bar's context menu and does not expand example to https://www.example.com/.

Comment 1

[Chris Peterson [:cpeterson]]

Attachment: screenshot.png

Comment 2

[Marco Bonardo [:mak]]

How does the bug differ from Bug 1945424? Is there additional steps to get the context menu for the toolbar opening in content? I'm not sure why here it shows context menu for the address bar and there for the toolbar, if the steps are the same?

Comment 3

[Emilio Cobos Álvarez [:emilio]]

I think this is mostly a UX question. Do we want to:

1. Prioritize the built-in shortcut (current behavior).
2. Do the url canonicalization (pre-Sequoia behavior).
3. Move the canonicalization shortcut to Cmd+Enter (pre-firefox 64 behavior, from bug 237027).
4. Move it to some other key combination.

I think that if we want to do (2) we might need some widget changes, in particular, overriding contextMenuKeyDown to allow the browser to handle the keydown before the selection shows up.

That said, showing the context menu by keyboard is an important accessibility feature so I suspect we want to do 1/3/4 instead if we can.

Comment 4

[Marco Bonardo [:mak]]

Thanks Emilio for clarifying Bug 1945424 behavior, that answers my question.

Comment 5

[Chris Peterson [:cpeterson]]

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

How does the bug differ from Bug 1945424? Is there additional steps to get the context menu for the toolbar opening in content? I'm not sure why here it shows context menu for the address bar and there for the toolbar, if the steps are the same?

Bug 1945424 is about the context menu opening when trying to use the address bar's Ctrl+Enter shortcut (starting in Fx 134). This bug is about Ctrl+Enter no longer adding "www." and ".com" to the address bar string (starting in Fx 136).

The Ctrl+Enter shortcut works correctly in Chrome on macOS 15.2 Sequoia: it adds "www." and ".com" and it doesn't open a context menu.

Comment 6

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

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

Comment 7

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

The bug is marked as tracked for firefox136 (beta). However, the bug still isn't assigned.

:cbellini, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 8

[Donal Meehan [:dmeehan]]

:mak, pinging as triage owner. There are only 2 weeks left in beta for Fx136.
I'm wondering what the severity is and the priority for aligning on the next steps?

Comment 9

[Mark Banner (:standard8)]

We are awaiting for final feedback from the accessibility team, and then will try to implement it for this beta cycle.

Comment 10

[Marco Bonardo [:mak]]

Attachment: Bug 1945422 - Change Ctrl+Enter canonization to Cmd+Enter on MacOS, due to new Sequoia context menu shortcut. r=daisuke

Comment 11

[Marco Bonardo [:mak]]

I think we'll want a rel-note in Nightly 137 and, once uplifted, Beta 136.

Release Note Request (optional, but appreciated)
[Why is this notable]: MacOS Sequoia introduced a new default shortcut to open a context menu: Ctrl+Enter. This conflicts with address bar shortcut to complete search string (e.g. "example") to .com URLs. We are changing the shortcut on MacOS to Cmd+Enter. The existing pref browser.urlbar.ctrlCanonizesURLs is named after ctrl, though we think it's not worth changing it, as that would break existing resources pointing to it, and it's quite common on the Mac to replace ctrl with cmd in general.
[Affects Firefox for Android]: no
[Suggested wording]: Due to recent changes in MacOS Sequoia, the shortcut to complete search strings to .com addresses has been changed on MacOS from Ctrl+Enter to Cmd+Enter. The preference to disable this feature, browser.urlbar.ctrlCanonizesURLs, was not renamed, and it's valid across all the supported platforms.
[Links (documentation, blog post, etc)]: -

Comment 12

[Marco Bonardo [:mak]]

We'll have to file a SUMO bug to update the shortcuts page

Comment 13

[Donal Meehan [:dmeehan]]

:mak, I see there is a patch pending review. There are only two beta builds left in the cycle for Fx136
Are there any concerns with landing and requesting an uplift this week?

Comment 14

[Marco Bonardo [:mak]]

No concerns, just a bit of delay. I'm updating the patch.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6c1483bf5f26
Change Ctrl+Enter canonization to Cmd+Enter on MacOS, due to new Sequoia context menu shortcut. r=daisuke,urlbar-reviewers

Comment 16

[agoloman]

Backed out for causing bc failures @browser_searchSuggestions.js.

• Backout link
• Push with failures
• Failure Log

Comment 17

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/06d540d058a1
Backed out changeset 6c1483bf5f26 for causing bc failures @browser_searchSuggestions.js. CLOSED TREE

Comment 18

[Marco Bonardo [:mak]]

that test needs an update. I didn't notice it on Try :(

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0fb970d47ef2
Change Ctrl+Enter canonization to Cmd+Enter on MacOS, due to new Sequoia context menu shortcut. r=daisuke,urlbar-reviewers

Comment 20

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/0fb970d47ef2

Comment 21

[Marco Bonardo [:mak]]

Attachment: Bug 1945422 - Change Ctrl+Enter canonization to Cmd+Enter on MacOS, due to new Sequoia context menu shortcut. r=daisuke

Original Revision: https://phabricator.services.mozilla.com/D238060

Comment 22

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: ctrl+Enter doesn't canonize search strings to url anymore on MacOS due to OS changes
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Canonization consists into converting a single word search string into a .com url, by pressing ctrl+Enter on Win/Lin and Cmd+Enter on MacOS
• Risk associated with taking this patch: low
• Explanation of risk level: we conditioned the modifier key on the platform, the code remained pretty much the same and it's covered by automated tests
• String changes made/needed: none
• Is Android affected?: no

Comment 23

[Pascal Chevrel:pascalc]

Note added to our nightly release notes in the Changed section

Comment 24

[Marco Bonardo [:mak]]

ni myself to file the SUMO bug.

Comment 25

[Raluca Popovici, Desktop QA]

Verified as fixed on MacOS 13.2.1 using Nightly 137.0a1(2025-02-21). On Win/ Lin, the command "CTRL+Enter" works as expected.
I reproduced this issue on MacOS 13.2.1 using Fx 136.0b7 and Fx 135.0.1.

Comment 26

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/7b4981ce79c9

Comment 27

[Raluca Popovici, Desktop QA]

Verified as fixed on MacOS 13.2.1, MacOS 11.7.1 and MacOS 15.3.1 using treeherder build Fx 136.0b10.

Comment 28

[Marco Bonardo [:mak]]

Filed SUMO ticket.

Comment 29

[Rob Wu [:robwu]]

This bug assigns a new action to Cmd+Enter, but that key already had some behavior before: opening a URL in a new tab. This shortcut change is disruptive to my flow, because now instead of a new tab, pressing Cmd+Enter replaces the current tab. This loss of functionality is not called out anywhere in this bug (only indirectly, by referring to bug 237027), nor in the release notes. Setting browser.urlbar.ctrlCanonizesURLs to false does allow me to open urlbar input in a new tab as before. I think that it would be useful to call out this change in the release notes.

comment 11 suggests the following wording:

[Suggested wording]: Due to recent changes in MacOS Sequoia, the shortcut to complete search strings to .com addresses has been changed on MacOS from Ctrl+Enter to Cmd+Enter. The preference to disable this feature, browser.urlbar.ctrlCanonizesURLs, was not renamed, and it's valid across all the supported platforms.

Here is an example of a phrasing that states how the "open in new tab" behavior can be restored.

[Suggested wording]: Due to recent changes in MacOS Sequoia, the shortcut to complete search strings to .com addresses has been changed on MacOS from Ctrl+Enter to Cmd+Enter. To disable this feature, set the browser.urlbar.ctrlCanonizesURLs preference to false. With this preference set to false, Cmd+Enter opens the address in a new tab, as before.

Comment 30

[Marco Bonardo [:mak]]

(In reply to Rob Wu [:robwu] from comment #29)

This bug assigns a new action to Cmd+Enter, but that key already had some behavior before: opening a URL in a new tab.

We're tracking that in bug 1949999.

I concur having a more detailed note may help, though I don't think we should pass the message we're breaking opening in new tab deliberately, since we're not.
The shortcut to open in new tab for the urlbar is alt+Enter across all the platforms. cmd+enter happened to work as an alternative on MacOS (from when we moved canonization to ctrl+enter few years ago).

Thus, I'd replace the ", as before." part with ", like Alt+Enter.", or just remove it.