Closed Bug 1945422 Opened 21 days ago Closed 3 days ago

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

Categories

(Firefox :: Address Bar, defect, P1)

Unspecified
macOS
defect

Tracking

()

VERIFIED FIXED
137 Branch
Tracking Status
relnote-firefox --- ?
firefox-esr115 --- unaffected
firefox-esr128 --- unaffected
firefox134 --- unaffected
firefox135 --- unaffected
firefox136 + fixed
firefox137 --- verified

People

(Reporter: cpeterson, Assigned: mak, NeedInfo)

References

(Regressed 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [sng])

User Story

CTRL+Enter has a new behavior in MacOS Sequoia that conflicts with the address bar "canonization" behavior (adding www. and .com to generate URLs from words).

Attachments

(3 files)

[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/.

Flags: needinfo?(emilio)
Attached image screenshot.png
See Also: → 1945424
Component: Widget: Cocoa → Address Bar
Product: Core → Firefox
Summary: Ctrl+Enter keyboard shortcut in the address bar no longer adds "www." and ".com" on macOS → Ctrl+Enter keyboard shortcut in the address bar no longer adds "www." and ".com" to the address bar string on macOS

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?

Flags: needinfo?(cpeterson)

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.

Flags: needinfo?(emilio)
See Also: → 237027

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

Flags: needinfo?(cpeterson)
User Story: (updated)

(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.

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

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.

Flags: needinfo?(cbellini)

: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?

Flags: needinfo?(mak)

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

Assignee: nobody → mak
Severity: -- → S2
Flags: needinfo?(mak)
Flags: needinfo?(cbellini)
Priority: -- → P1
Whiteboard: [sng]

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)]: -

relnote-firefox: --- → ?

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

: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?

Flags: needinfo?(mak)

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

Flags: needinfo?(mak)
Pushed by mak77@bonardo.net: 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

Backed out for causing bc failures @browser_searchSuggestions.js.

Flags: needinfo?(mak)
Backout by csabou@mozilla.com: https://hg.mozilla.org/mozilla-central/rev/06d540d058a1 Backed out changeset 6c1483bf5f26 for causing bc failures @browser_searchSuggestions.js. CLOSED TREE

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

Flags: needinfo?(mak)
Pushed by mak77@bonardo.net: 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
Status: NEW → RESOLVED
Closed: 3 days ago
Resolution: --- → FIXED
Target Milestone: --- → 137 Branch
Attachment #9467524 - Flags: approval-mozilla-beta?

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
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

Note added to our nightly release notes in the Changed section

ni myself to file the SUMO bug.

Flags: needinfo?(mak)

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.

Status: RESOLVED → VERIFIED
Blocks: 1945424
See Also: 1945424
Regressions: 1949999
Attachment #9467524 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: