Inconsistent shortcuts for new tab

[André Rüdiger]

There are currently too many shortcuts when opening a link in a new tab:

 - location bar: <ALT> + <ENTER>
 - GO button: <CTRL> + click
 - search bar: <CTRL> + <ENTER>
 - SEARCH button <ALT> + click
 - links: <SHIFT> + click
 - menu bar: <CTRL> + click
 - BACKWARD/FORWARD button: <CTRL> + click

This is one of the reasons I'm keeping with Opera. There it is always the shift key and I have to remember only one key.

Thanks for reading!

[Jruderman (jruderman)]

The address bar doesn't use Ctrl+Enter for opening a URL in a new tab because IE
users are used to it adding "www." and ".com".

[Mike Connor (mconnor)]

I think we need to revisit this before 1.0. However, I think this is a dupe...

[Mohr-42 (mohr-42)]

This simply says Ctrl+Enter is used to open a link in a new tab that is selected
with, say, Find as You Type, and that Alt+Enter is used to open a link in a new
tab from the location bar. I don't believe there are any bugs that cover this
specifically, but there are many saying that Ctrl+Enter doesn't work as expected
from the location bar (I don't think this is adequately covered for people
switching to Firefox from Mozilla).

I used Mozilla for a long time and originally hated having to use Alt+Enter on
Firefox, but now that I've gotten used to that, Ctrl+Enter on links that are
selected seems weird--both should use Ctrl, or both should use Alt.

[Prognathous (prognathous)]

(In reply to comment #3)
> I used Mozilla for a long time and originally hated having to use Alt+Enter on
> Firefox, but now that I've gotten used to that, Ctrl+Enter on links that are
> selected seems weird--both should use Ctrl, or both should use Alt.

I generally agree, but there's a third option that is compatible with both
browsers. See Bug 177498, comment 16.

Prog.

[Mohr-42 (mohr-42)]

bug 177498 comment 16:
> Ctrl+Enter in the address bar should add www...com if the string has no dots
> (e.g. 'cnn' -> 'www.cnn.com'). This should also apply to 'about:' addresses
> and the like.
>
> Ctrl+Enter in the address bar should open in new tab if the string is a part
> of URI, with at least one dot (e.g. 'cnn.com' -> New-Tab/cnn.com)
>
> Ctrl+Enter on links should open them in a new tab, like it does today.

I still favor a preference, so that I could use a keyword with Ctrl+Enter and
get a new tab (whether this is something you planned on or not is ambiguous).

[Bkuemmer (bkuemmer)]

Created an attachment (id=161856)
Firefox extension to exchange Ctrl-Enter and Alt-Enter behaviour in the URL Bar

So, this has bugged me so long that I have written a small extension which just
exchanges the behaviour of Ctrl-Enter and Alt-Enter in the URLBar of Firefox...
I am sure there are better ways to distribute this (and better ways to solve
this), but as of now, I am attaching this extension here, maybe it is just what
some people needed.

Just install it, this will bring back the old mozilla behaviour of opening a
new Tab when pressing Ctrl-Enter in the URL Bar. To not lose any functionality,
this also maps Alt-Enter to the Firefox Auto-Complete feature (i.e. pad the
entered string with www.*.com), I never use this, so I don't know if this is
really wanted.

Uninstalling this extension brings back the default Firefox behaviour.

This was only tested on Firefox 1.0PR

A nice update to this extension would be to have a preference key to switch
this behaviour on and off, but for me, uninstalling is OK.

[Dtownsend (dtownsend)]

*** Bug 302492 has been marked as a duplicate of this bug. ***

[André Rüdiger (andreruediger-deactivatedaccount)]

Wouldn't it be more consistent if we had ONE shortcut
for this behavior instead of three (search and address bar -> alt, bookmarks ->
ctrl, links -> shift)?

I think shift would be a good choice, cause even IE-users are used to it. Would
be nice if anytime a button (bookmark, go-buttom, back-button,...) is pressed to
request an url, while holding a predefined key (i.e. shift/ctrl), firefox uses
the same behavior - open new tab/open new tab in background.

[Bkuemmer (bkuemmer)]

Created an attachment (id=205205)
Firefox extension to exchange Ctrl-Enter and Alt-Enter behaviour in the URL Bar (Update for FF 1.5)

[Bkuemmer (bkuemmer)]

Created an attachment (id=211147)
Firefox extension to exchange Ctrl-Enter and Alt-Enter behaviour in the URL Bar (Update for FF > 1.5)

Since FF 1.5.1 has been released, I had to update this mini-extension. It now will be installable up through FF 1.9

[Beltzner (beltzner)]

(In reply to comment #1)
> The address bar doesn't use Ctrl+Enter for opening a URL in a new tab because
> IE users are used to it adding "www." and ".com".

I think this legacy support for an advanced use case at the cost of inconsistency hinders more than it helps. We continually promote the crap out of tabbed browsing, and should be able to make clean and clear statements like "hold ctrl to have your action create a new tab."

People who are used to accel-enter adding www...com will adapt pretty quickly, and I'd rather piss off that minority user group than confuse people who have downloaded our browser to get easy tabbed browsing behaviour.

[Rhmzgx56 (rhmzgx56)]

It also seems inconsistent to me that:
 - if I right-click a link on a page, the accelerator key for "Open Link in New Tab" is "T"
 - if I right-click a link in Bookmarks, the accelerator key for "Open in New Tab" is "W"
 - If I right-click a link on a page, the accelerator key for "Open Link in New Window" is "W"

Let us not forget that some people must or prefer to spend more time with the keyboard and less with the mouse, and consistency in such things is important.

Thanks.

[André Rüdiger (andreruediger-deactivatedaccount)]

There are currently too many shortcuts when opening a link in a new tab:

 - location bar: <ALT> + <ENTER>
 - GO button: <CTRL> + click
 - search bar: <CTRL> + <ENTER>
 - SEARCH button <ALT> + click
 - links: <SHIFT> + click
 - menu bar: <CTRL> + click
 - BACKWARD/FORWARD button: <CTRL> + click

This is one of the reasons I'm keeping with Opera. There it is always the shift key and I have to remember only one key.

Thanks for reading!

[Bkuemmer (bkuemmer)]

Created an attachment (id=243585)
Firefox extension to exchange Ctrl-Enter and Alt-Enter behaviour in the URL Bar (Update for FF >= 2.0)

Another update of the mini extension to be usable for FF 2.*

[David Farning (dfarning)]

There are additional usability comments at https://bugs.launchpad.net/distros/ubuntu/+source/firefox/+bug/66566

Dave

[David Farning (dfarning)]

These inconsistencies are recognized upstream.

Dave

[Pile0nades (pile0nades)]

(In reply to comment #13)
> Created an attachment (id=243585) [details]
> Firefox extension to exchange Ctrl-Enter and Alt-Enter behaviour in the URL Bar
> (Update for FF >= 2.0)
>
> Another update of the mini extension to be usable for FF 2.*
>

You should submit the extension to https://addons.mozilla.org/ so more people can use it. It took me a little while to find this bug and extension.

[Philringnalda (philringnalda)]

beltzner: gut-check and UI-wanted - I patched this, it's simple, and then since ctrl+enter opened a new tab, I tried shift+enter, expecting a new window, and instead got www. and .net wrapped. ui? for that. Then I fired up IE7 to check its keyboard shortcuts, and found that not only does it still use ctrl+enter for www. and .com, it also uses alt+enter for open-in-new-tab. Still want to change?

[Mike Hicks (hick0088)]

A historical note: The old Netscape browser was pretty good about adding the www. and .com strings to a hostname in the URL bar automatically. Well, it did a good job on Unix/Linux boxes anyway -- it never worked as smoothly on Windows systems for some reasons (maybe DNS lookups took longer on Windows?).

Anyway, since that worked so well on my Linux box, I got accustomed to just typing in "cnn" or whatever, pressing Enter, and letting the browser do the thinking for me. No Ctrl+Enter required.

Maybe it should just be off by default, and Ctrl+Enter should just behave like pressing Enter unless the user says they want different behavior (personally I want Ctrl+Enter to open a new tab, but if people are going to say "That's not the way IE does it", then I'd rather have it not do anything special by default).

[Westacular+mozilla (westacular+mozilla)]

Why not make a preference to choose between the current behaviour for modifier+enter in the url and search bars and what would be consistent behaviour?

e.g., browser.urlbar.modifierAction

Setting 1 is everything as it stands currently.

Setting 2 disables the URL 'fixup' feature makes the behaviour when hitting enter in the url and search bars consistent with the rest of Firefox:

ctrl+enter = new tab
shift+enter = new window
alt+enter = save target

I suggest lumping search bar behaviour in with the url bar because as far as I can tell the only reason the search bar uses alt+enter for new tab currently is to be consistent with the url bar. (shift and ctrl currently have no effect.)

I really think a preference is warranted here; the inconsistency is really quite glaring and unnecessary to new/non-IE users (or anyone who doesn't find the fixup useful), but there is an entrenched (and likely vocal) part of the community that likes things they way they are right now. It would only take a handful of extra lines in browser.js and search.xml.

[Jruderman (jruderman)]

*** Bug 384073 has been marked as a duplicate of this bug. ***

[Philringnalda (philringnalda)]

*** Bug 410945 has been marked as a duplicate of this bug. ***

[Philringnalda (philringnalda)]

*** Bug 429740 has been marked as a duplicate of this bug. ***

[Bj02455+bugzilla (bj02455+bugzilla)]

So, this has been discussed for four years now, but nobody has bothered to make a change? Even one as simple as Comment #18? What the heck is going on here?

[André Rüdiger (andreruediger-deactivatedaccount)]

To summarize the current (IMHO weird) behaviour:
Links:
  [CTRL] + [ENTER] -> new Tab
  [CTRL] + [SHIFT] + [ENTER] -> new Tab in background
  [SHIFT] + [ENTER] -> new Window
  [ALT] + [ENTER] -> save as...
  (same behaviour for clicks instead of [ENTER])

Location Bar:
  [CTRL] + [ENTER] -> new Tab
  [CTRL] + [ALT/SHIFT] + [ENTER] -> new Tab
  [ALT/SHIFT] + [ENTER] -> same Tab

Search Bar:
  [ALT] + [ENTER] -> new Tab
  [CTRL/SHIFT] + [ENTER] -> some Tab

History/Bookmarks:
  [CTRL] + [ENTER] -> new Tab
  [CTRL] + [SHIFT] + [ENTER] -> new Tab in Background
  [SHIFT] + [ENTER] -> new Window
  [ALT] + [ENTER] -> doesn't work for menus
  (same behaviour for clicks instead of [ENTER])

Proposal:
  "new Tab" Accelerator (default: [SHIFT])
  "new Window" Accelerator (deafult: [CTRL])
  "in Background" Accelerator (default: [CTRL])
  "auto Complete" Accelerator (default: [ALT])
  "save as" Accelerator (default: [ALT])
these Accelerators are user customizable via preferences. [SHIFT] and [CTRL] could be switched although [SHIFT] is the "new Tab" default for IE.

So for Links, Location Bar, Search Bar, History and Bookmarks:
  [new Tab] + [ENTER] -> new Tab
  [new Tab] + [in Background] + [ENTER] -> new Tab in background
  [new Window] + [ENTER] -> new Window
  [auto Complete] + [ENTER] -> auto complete (Loaction and Search Bar only)
  [save as] + [ENTER] -> save link as (Links, History and Bookmarks only)
  (same behaviour for clicks instead of [ENTER])

So whenever I click or press [ENTER] I know what will happen no matter where. (Again: Just take a look at Opera...)

[Beltzner (beltzner)]

This will not block the final release of Firefox 3.1.

[Brittany Dunlap (xdunlapx)]

Some people like alt and some like control. Personally for a new tab I just right-click to open in new tab OR double click the tab bar to open a new blank tab.

I don't see how this is a bug that necessarily needs fixed as each browser has different shortcuts and options, so saying Opera only has one shortcut for 'open in new tab' does not mean that firefox should only have one.

I do see this bug report is old and still open... Perhaps that's for the better.

[Philringnalda (philringnalda)]

*** Bug 476907 has been marked as a duplicate of this bug. ***

[Rhmzgx56 (rhmzgx56)]

(In reply to comment #23)

Do not forget about folks using Apple Mac OS X, with a somewhat different set of key bindings than is generally found on Windows and/or Linux systems.

[Ra4ul (ra4ul)]

Created an attachment (id=385613)
preference to swap modifier keys

browser.urlbar.swapModifier (boolean)
false: current
true: ctrl (cmd) -> new tab, alt (ctrl) -> completion, (alt) -> download
the deviation on mac is to match safari.

i could add a third, unified option a la comment #18 at the risk of obfuscating the code.

[Gavin Sharp (gavin-sharp)]

(From update of attachment 385613)
I haven't looked closely at the patch, but we're not going to end up adding a pref for this. It increases code complexity and only really benefits users who would likely otherwise be comfortable installing an extension. I would encourage you to package up this change as an extension.

[pmow (pmow)]

That sounds like this bug is supposed to be wontfix...

[Bkuemmer (bkuemmer)]

Since FF 3.5 unfortunately broke my own little extension (attachment 243585), I hunted around and found "Advanced Address Bar" at https://addons.mozilla.org/en-US/firefox/addon/9450

This allows you to freely configure the Shift-, Ctrl- and Alt- behavior in the urlbar, which is really great! Until now, it does not officially support FF 3.5, but it works if you make it compatible using MR Tech Toolkit https://addons.mozilla.org/en-US/firefox/addon/421

[Gavin Sharp (gavin-sharp)]

*** Bug 503232 has been marked as a duplicate of this bug. ***

[Mozdev-caseyconnor (mozdev-caseyconnor)]

Rather than start a new bug, which I was about to do, it seems as if this bug encompasses my issue as well: I wanted the ability to open new tabs from the search bar without switching to them (as happens with alt-enter).

I created an extension:
https://addons.mozilla.org/en-US/firefox/addon/13884

All it does: at line 482 of:
http://mxr.mozilla.org/mozilla1.9.1/source/browser/components/search/content/search.xml

...add the line:

          if (aEvent.ctrlKey) where = "tabshifted";

Of course it may not groove with suggestions above, but perhaps it helps something. Further, it's my first time in this code and it may not be a great solution.

[Mozdev-caseyconnor (mozdev-caseyconnor)]

New extension:
https://addons.mozilla.org/en-US/firefox/addon/13930/

...same as previous, but handles search bar and URL bar.

Seems to only work for FF 3.5.*

[Micah Gersten (micahg)]

Firefox 2 is EOL.

[Micah Gersten (micahg)]

Firefox 3.0 is only receiving Security Updates and major bug fixes at this point.

[Micah Gersten (micahg)]

This is not a security vulnerability. Still waiting on upstream for a fix.

[Hskupin (hskupin)]

*** Bug 513180 has been marked as a duplicate of this bug. ***

[Alexander-kern (alexander-kern)]

(Yeah, but not using the URL bar is just not as nice. For example look & feel, use search & bookmarks keywords, afaik.)

Ah thanks, I missed the mention of that pref! Well I'd rather have it not be consistent, but I understand your reasoning and gave my opinion.

Still, should the combinations not stack like ctrl+shift canonize and open in new window? alt+ctrl does already stack as expected (canonize and open new tab). Why does only that stack? And alt+shift to open in new background tab would be incredibly useful for users who don't want to mess with about:config or don't know about it. They can just find it by trying it out or understanding how stacking should work.

Anyway this is a followup issue and you said you wanted this bug to be closed, so if I don't hear back soon I'll submit a new ticket. Thanks!

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

(In reply to alexander.kern from comment #125)
> (Yeah, but not using the URL bar is just not as nice. For example look &
> feel, use search & bookmarks keywords, afaik.)

Yep... perhaps there's room for webextensions to have a larger scope for interaction with the URL bar - you could file a bug in the webextensions product.

> Ah thanks, I missed the mention of that pref! Well I'd rather have it not be
> consistent, but I understand your reasoning and gave my opinion.

Likewise! It's a tricky problem - I was joking on IRC the other day that really we need like 10 modifier keys instead of just 3, then it wouldn't be so hard to come up with a way to make things not conflict...

> Still, should the combinations not stack like ctrl+shift canonize and open
> in new window? alt+ctrl does already stack as expected (canonize and open
> new tab). Why does only that stack? And alt+shift to open in new background
> tab would be incredibly useful for users who don't want to mess with
> about:config or don't know about it. They can just find it by trying it out
> or understanding how stacking should work.
>
> Anyway this is a followup issue and you said you wanted this bug to be
> closed, so if I don't hear back soon I'll submit a new ticket. Thanks!

Yes, please submit a new bug for alt-shift / ctrl-shift. :-)

[Mozdev-l (mozdev-l)]

Hi -- I developed (an overstatement, maybe) the now-defunct extension Background Tabs which allowed ctrl-enter to open URL bar and search bar items in a background tab. I was excited to see this:

> This behavior is now possible, but it's behind a pref (about:config, browser.urlbar.ctrlCanonizesURLs)

...does that mean that a user will be able to change that pref and then ctrl-enter in the URL bar will open a background tab without switching to it?

Will there be a similar option for the search bar? (Consistency would seem to dictate that there should be?)

[Alexander-kern (alexander-kern)]

Hi! Yes it is possible! Well no to be exact, not possible with ctrl+enter but with ctrl+shift+enter instead. You can try the newest nightly/alpha/Aurora version of Firefox and test it out yourself. So you could use it right now :-)

So if Webextensions can modify about:config settings you could revive your extension but with ctrl+shift+enter instead. I don't think it's possible for Webextensions to edit that keyboard command (some others like ctrl+f are possible to rewrite though). If you want to track progress on that issue, it is https://bugzilla.mozilla.org/show_bug.cgi?id=1215061
However enter is not even a keyboard shortcut I suppose so it is probably not affected by that issue, right?

Oh and it's not possible with the search bar right now! They don't seem to share the code. Is that considered as a bug? :Gijs?

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

(In reply to alexander.kern from comment #128)
> Oh and it's not possible with the search bar right now! They don't seem to
> share the code. Is that considered as a bug? :Gijs?

Could you file a separate issue, and we can work out if it's fixable there? IIRC there are some other subtleties with how search behaves (e.g. defaults for whether tabs open in the foreground or not when you use the page context menu to search are governed by a different pref to the one governing "normal" links opened in tabs). So I'm not sure off-hand how easy it would be to fix. Either way we usually try to fix 1 thing per bug to avoid confusion about what is/isn't fixed. So fixing the search bar, given that it's not using the same code as per your comment, will need to have its own bug.

[Mozdev-l (mozdev-l)]

That's fantastic, thanks for attending to it! I'll miss ctrl-enter, but ctrl-shift-enter is a perfectly reasonably compromise. :-)

I filed bug #1490138 for the search bar (hopefully I got the details right).

I probably won't bother making a new extension just for the about:config pref. If the search bar implements something similar as well, Background Tabs will be happily obsolete!

[Maruf-rahman-95 (maruf-rahman-95)]

I have reproduced this bug with Nightly version 1.0+ (2004-12-14)[] on Windows 7, 64 Bit!
User agent- Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.8a6) Gecko/20041224 Firefox/1.0+

Thus bug's fix is verified with latest Nightly!

Build ID 20180927220034
User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

[Julien Cristau (jcristau-mozilla)]

Added to 64beta release notes:
Changes to URL bar autocomplete keyboard shortcuts: use ctrl-enter for URL canonicalization on all platforms, and offer an opt-out for Windows/Linux users where it interferes with opening URLs in (background) tabs

[Alexander-kern (alexander-kern)]

Followup issues for inconsistencies of combinations and search input added:
https://bugzilla.mozilla.org/show_bug.cgi?id=1506203
https://bugzilla.mozilla.org/show_bug.cgi?id=1506247
respectively.

[David-balazic (david-balazic)]

How exactly is this fixed? Where?

The https://www.mozilla.org/en-US/firefox/64.0/releasenotes/ doesn't mention it.

(In reply to Julien Cristau [:jcristau] from comment #132)
> Added to 64beta release notes:
> Changes to URL bar autocomplete keyboard shortcuts: use ctrl-enter for URL
> canonicalization on all platforms, and offer an opt-out for Windows/Linux
> users where it interferes with opening URLs in (background) tabs

Was this dropped for the final release?

What is the opt-out mechanism?

PS: Bugzilla needs a "final summary" field where things like this are documented.

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

(In reply to David Balažic from comment #134)
> How exactly is this fixed? Where?
>
> The https://www.mozilla.org/en-US/firefox/64.0/releasenotes/ doesn't mention
> it.

It does:

"The macOS keyboard shortcut to add "www" and ".com" to a URL is now ctrl-enter instead of [apple]-enter"

This is the only by-default change here. See the end of comment 124.

> (In reply to Julien Cristau [:jcristau] from comment #132)
> > Added to 64beta release notes:
> > Changes to URL bar autocomplete keyboard shortcuts: use ctrl-enter for URL
> > canonicalization on all platforms, and offer an opt-out for Windows/Linux
> > users where it interferes with opening URLs in (background) tabs
>
> Was this dropped for the final release?

No, the relnote just got repeatedly rewritten to simplify it and make it understandable/relevant for people who hadn't followed this bug.

> What is the opt-out mechanism?

On Windows/Linux you can change this by setting `browser.urlbar.ctrlCanonizesURLs` to false.

[SyKoTiK (sybercorp)]

On macOS, how can I bring back CMD-Enter for URL completion? I do not want CTRL-Enter on macOS, and I can't seem to find the option in about:config to change it back.

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

(In reply to Jesse Peden from comment #136)
> On macOS, how can I bring back CMD-Enter for URL completion? I do not want
> CTRL-Enter on macOS, and I can't seem to find the option in about:config to
> change it back.

There isn't one. Ctrl-Return is consistent with Safari and Chrome on mac.

[SyKoTiK (sybercorp)]

(In reply to :Gijs (he/him) from comment #137)
> (In reply to Jesse Peden from comment #136)
> > On macOS, how can I bring back CMD-Enter for URL completion? I do not want
> > CTRL-Enter on macOS, and I can't seem to find the option in about:config to
> > change it back.
>
> There isn't one. Ctrl-Return is consistent with Safari and Chrome on mac.

I suppose it is, but it seems to be counter-productive to get users used to having it be CMD-Enter for all of these years and then change it out of the middle of nowhere. They could have at least added an option to allow people to opt out of it.

[Alexander-kern (alexander-kern)]

Jesse, you can follow the progress of the issue/bug for better keyboard shortcut control here https://bugzilla.mozilla.org/show_bug.cgi?id=1215061
When it's done there can be extensions that change this behavior. It is a bit unfortunate the change to webextensions was rushed and now we are missing some features.

:Gijs, I don't know how to tag people here so I hope posting here again is ok to contact you. Could you show me the lines where you changed this code so I can have a look at it? Because on the issue I created it was said that it might be too much development effort to fix the issue (resolving the inconsistency of pressing multiple modifiers and enter in the navbar). Thank you!

[J-nox (j-nox)]

The keyboard shortcut cmd-enter opens links in new *background* tabs in Chrome and Safari, Firefox is now opening them in new *foreground* tabs. Is there any way to change this behaviour?

[Mak77 (mak77)]

(In reply to Anthony Ramine [:nox] from comment #140)
> The keyboard shortcut cmd-enter opens links in new *background* tabs in
> Chrome and Safari, Firefox is now opening them in new *foreground* tabs. Is
> there any way to change this behaviour?

Please file a new bug, if the behavior is inconsistent with Chrome and Safari we'll look into it.

[J-nox (j-nox)]

It's kinda the topic of this bug, though, see its title:

> for Windows/Linux users where it interferes with opening URLs in (background) tabs

[Mak77 (mak77)]

(In reply to Jesse Peden from comment #138)
> I suppose it is, but it seems to be counter-productive to get users used to
> having it be CMD-Enter for all of these years and then change it out of the
> middle of nowhere. They could have at least added an option to allow people
> to opt out of it.

We must evolve, and on certain things that means also reaching consensus and coherence with the other browsers, so that users can easily find themselves comfortable moving across them (even if just for development, testing, web-compat issues). Unfortunately in some cases this means changing behaviors that have been with us from a long time (I'm here from 11 years, I know well).
If we'd add a pref for each change, in a few years the code would become totally unmanageable. Surely adding one pref here looks like a no-brainer, but if you multiple that by the hundreds of times I heard someone asking for a pref, you can easily see it's not sustainable long term.
Breaking habits and muscle memory is bad, we don't do that often and we try to avoid it, but when an habit hurts a part of our users and it's inconsistent with the rest of the browsers world, we may actually look into it. This was one case, there have been others, there will be others.

[avada (dqeswn)]

(In reply to Marco Bonardo [::mak] from comment #141)
> (In reply to Anthony Ramine [:nox] from comment #140)
> > The keyboard shortcut cmd-enter opens links in new *background* tabs in
> > Chrome and Safari, Firefox is now opening them in new *foreground* tabs. Is
> > there any way to change this behaviour?
>
> Please file a new bug, if the behavior is inconsistent with Chrome and
> Safari we'll look into it.

I think it's also inconsistent with Firefox itself. "browser.tabs.loadDivertedInBackground;true" should apply for this too at least.

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

(In reply to alexander.kern from comment #139)
> :Gijs, I don't know how to tag people here so I hope posting here again is
> ok to contact you. Could you show me the lines where you changed this code
> so I can have a look at it? Because on the issue I created

I commented on bug 1506203.

[Uhr80386 (uhr80386)]

What happened so shift+enter and ctrl+shift+enter?
Up to know shift+enter did .net and ctrl+shift+enter did .org.. now it does open a new window or simply use .com.

That's not how it should be.
How can I change it back?

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

(In reply to uhr80386 from comment #146)
> What happened so shift+enter and ctrl+shift+enter?
> Up to know shift+enter did .net and ctrl+shift+enter did .org.. now it does
> open a new window or simply use .com.

They were removed to enable support for opening URLs in a new window. No other browser implements these, and with the current set of available TLDs being rather different from those of the late 90s, there didn't seem a good reason to keep this behaviour. There isn't a pref to revert that change.

[Gpy98671 (gpy98671)]

(In reply to :Gijs (he/him) from comment #147)
> No other browser implements these

That's my point!
It's extremely usefull for fast navigation, at least for me or my colls at work.
Of course you can type in .net or .org, use favorites, or something else.
But I don't the point in linking opening URLs in a new window with that - even if its old - feature.
It might be a relic and not know to many users, but I would like at least have the chance to decide if I want the new or the old feature.

Now I'm pretty upset about the latest Firefox, there were already a lot things I missed during the latest versions, but that one is a real issue.

[Alexander-kern (alexander-kern)]

(In reply to gpy98671 from comment #148)

gpy98671 until the team changes it's opinion on this, which doesn't look likely, there would need to be an extension to get your desired functionality back. However AFAIK webextensions do not have this capability right now. You can join the conversation here to follow the progress and/or help/get help: https://bugzilla.mozilla.org/show_bug.cgi?id=1215061

[smmalis37 (smmalis37)]

> What happened so shift+enter and ctrl+shift+enter?
> Up to know shift+enter did .net and ctrl+shift+enter did .org.. now it does
> open a new window or simply use .com.

I've been a Firefox user for years now. I use these keyboard shortcuts daily. net and org are still extremely common TLDs, even with others becoming more common. This change is annoying enough for me to seriously consider downgrading to 63. I ask the Firefox team to please consider reverting this change until there is a way for this functionality to be supported by an extension. I'll even write the extension myself, but judging by https://bugzilla.mozilla.org/show_bug.cgi?id=1215061 such an extension isn't possible yet.

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

(In reply to smmalis37 from comment #150)
> > What happened so shift+enter and ctrl+shift+enter?
> > Up to know shift+enter did .net and ctrl+shift+enter did .org.. now it does
> > open a new window or simply use .com.
>
> I've been a Firefox user for years now. I use these keyboard shortcuts
> daily. net and org are still extremely common TLDs, even with others
> becoming more common. This change is annoying enough for me to seriously
> consider downgrading to 63. I ask the Firefox team to please consider
> reverting this change until there is a way for this functionality to be
> supported by an extension.

I don't see this happening. Consistency both with other browsers and other shortcuts trumps the need for alternative domain autocompleting (and really, without the other browsers it would probably have trumped .com autocomplete, too).

I'm also really quite confused by the .net / .org case - do you turn off autocomplete and/or history (in the location bar), or something? Why can't you just hit "normal" enter when the domain you want gets autocompleted? Do you just visit new .net/.org domains (where you somehow do know the exact TLD you want, so you don't use a search engine, but you have never visited before) every day? That seems like a very niche usecase...

In terms of add-ons, it'd be pretty trivial to write an add-on that just provided you a toolbar button that, when clicked (or activated via a new shortcut of the add-on's choosing), provided an alternative input, where you could type anything and it'd just suffix '.net' or '.org' and navigate the current URL to it. I accept that's quite kludgy, but if you really can't use autocomplete / history for this and are annoyed at typing '.net' or '.org' after URLs, I think that might currently be your best option.

[Abhro-r-dev (abhro-r-dev)]

(In reply to :Gijs (he/him) from comment #151)
> (In reply to smmalis37 from comment #150)
> > > What happened so shift+enter and ctrl+shift+enter?
> > > Up to know shift+enter did .net and ctrl+shift+enter did .org.. now it does
> > > open a new window or simply use .com.
> >
> > I've been a Firefox user for years now. I use these keyboard shortcuts
> > daily. net and org are still extremely common TLDs, even with others
> > becoming more common. This change is annoying enough for me to seriously
> > consider downgrading to 63. I ask the Firefox team to please consider
> > reverting this change until there is a way for this functionality to be
> > supported by an extension.
>
> I don't see this happening. Consistency both with other browsers and other
> shortcuts trumps the need for alternative domain autocompleting (and really,
> without the other browsers it would probably have trumped .com autocomplete,
> too).
>
> I'm also really quite confused by the .net / .org case - do you turn off
> autocomplete and/or history (in the location bar), or something? Why can't
> you just hit "normal" enter when the domain you want gets autocompleted? Do
> you just visit new .net/.org domains (where you somehow do know the exact
> TLD you want, so you don't use a search engine, but you have never visited
> before) every day? That seems like a very niche usecase...
>
> In terms of add-ons, it'd be pretty trivial to write an add-on that just
> provided you a toolbar button that, when clicked (or activated via a new
> shortcut of the add-on's choosing), provided an alternative input, where you
> could type anything and it'd just suffix '.net' or '.org' and navigate the
> current URL to it. I accept that's quite kludgy, but if you really can't use
> autocomplete / history for this and are annoyed at typing '.net' or '.org'
> after URLs, I think that might currently be your best option.

I do have history turned off, but visit previously visited sites that I do know that TLD for and do not need to search for, thus pressing [Ctrl+]Shift+Enter for .net / .org directly. I see the usefulness in being able to open new windows from the awesome bar, but the .net / .org is still widely enough used TLDs that such autocomplete is desired behavior for some. Any advice on reverting the behavior, or making a toggle between 'TLD autocomplete' and 'open address in new window' possible?

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

(In reply to Abhro from comment #152)
> I do have history turned off, but visit previously visited sites that I do
> know that TLD for and do not need to search for, thus pressing
> [Ctrl+]Shift+Enter for .net / .org directly. I see the usefulness in being
> able to open new windows from the awesome bar, but the .net / .org is still
> widely enough used TLDs

IME, less so across the globe - that is, if I'm in (say) France, I'd probably prefer `.fr`, in South Africa, .za, etc.

The .net/.org shortcut was always hardcoded, and as noted before, no other browser has shortcuts for any other domains.

> that such autocomplete is desired behavior for some.
> Any advice on reverting the behavior, or making a toggle between 'TLD
> autocomplete' and 'open address in new window' possible?

You can control the suffix of `.com` and change it to something else using the `browser.fixup.alternate.suffix` pref in about:config , if you like. You could also use bookmarks for the sites you use regularly enough that you know the TLD, so that you don't need a modifier key at all and can probably hit enter sooner (TBH, I suspect this is likely to be an improvement for your usecase). As I already said in comment #150, I don't think we'll bring back (an option to use) separate modifier keys for .net/.org. Marco, can you confirm?

[Joshua Bell (eages)]

This change made me a little sad. I used the old hotkeys about a quarter or a third of every time I used the URL bar.

[Mak77 (mak77)]

(In reply to :Gijs (he/him) from comment #153)
> As I already said in comment #150, I don't think we'll bring
> back (an option to use) separate modifier keys for .net/.org. Marco, can you
> confirm?

No plain in sight.
You can star a page and use autofill for it though, if you access it often enough.

[Etienne Rastoul (s3phy)]

Wow, I realized a few days ago that Shift+Enter and Ctrl+Shift+Enter didn't work anymore, I thought it was a bug in my Linux distribution... I'm surprised to see that this was a deliberate decision. I've been using these keyboard shortcuts for years (probably more than a decade) and I've always missed them when using another browser (they're one of the reasons I've kept using Firefox all these years, when a lot of people I know moved to Chrome for example)

I do a lot of browsing in a private browsing window, so some websites I sometimes use are not (and never have been) in my navigation history or in my bookmarks. Neither do I want some of these websites in my history or bookmarks. It's almost become muscle memory after all these years to type the domain and Ctrl+Enter, Shift+Enter or Ctrl+Shift+Enter :)

I guess someone will make an extension to bring back that feature :) Or maybe I'll take the time to figure out how to do it myself, or I'll patch and compile my own Firefox to bring it back... but given that I'm too lazy to simply type .net or .org it doesn't look like any of this will happen haha

[Msisaac (msisaac)]

Here's my situation: I use a Mac, but I use a Windows keyboard. I changed my modifier keys in MacOS system preferences so that Control is now Cmd and Cmd is now Control. This means that I can use ctrl + key on my keyboard for shortcuts, just like I would use in Windows (ctrl + c to copy, ctrl + v to paste). If I didn't make that change in system preferences, I'd have to use the Windows key for those same shortcuts (win + c to copy, win + v to paste), which is not how the shortcuts work in Windows. Before Firefox 64, ctrl + enter on my Windows keyboard would autocomplete the URL with www. and .com, because I changed my modifier keys in system preferences. This behavior is consistent with how it would work using the same keyboard in Windows. Because of this change to Firefox 64, I now have to use win + enter in Firefox, or I have to change my system preferences modifier keys back to defaults, which means Firefox would again use ctrl + enter on the keyboard to autocomplete, but for everything else in the OS, I'd have to use the Win key. So Firefox is now the odd program on my Mac. I have to retrain my fingers to use win + enter on the Mac, but continue to use ctrl + enter on Windows.

So while this is really more of a nuisance than a true show-stopper, it would be nice if you offered a config that would revert the changes on Macs if the user isn't using a Mac keyboard.

[Anthony Sottile (asottile)]

this change is really unfortunate -- I just phished myself due to relying on muscle memory that dates back at least 10 years.

[Rhmzgx56 (rhmzgx56)]

Actually, it's not the change that is unfortunate, but that it took 15 years for it to happen. Back then, there were far fewer people who had developed the "wrong" muscle memory around it.

[Boobox (boobox)]

Is there another thread where we can upvote a possible feature to change this via an option?

[Bastien-l (bastien-l)]

(In reply to :Gijs (he/him) from comment #153)
> (In reply to Abhro from comment #152)
> > I do have history turned off, but visit previously visited sites that I do
> > know that TLD for and do not need to search for, thus pressing
> > [Ctrl+]Shift+Enter for .net / .org directly. I see the usefulness in being
> > able to open new windows from the awesome bar, but the .net / .org is still
> > widely enough used TLDs
>
> IME, less so across the globe - that is, if I'm in (say) France, I'd
> probably prefer `.fr`, in South Africa, .za, etc.
>
> The .net/.org shortcut was always hardcoded, and as noted before, no other
> browser has shortcuts for any other domains.
From a Belgian guy living in Luxembourg and Australia: Nope, you're wrong. .com, .net and .org are the most common extensions I type.
>
> > that such autocomplete is desired behavior for some.
> > Any advice on reverting the behavior, or making a toggle between 'TLD
> > autocomplete' and 'open address in new window' possible?
>
> You can control the suffix of `.com` and change it to something else using
> the `browser.fixup.alternate.suffix` pref in about:config , if you like. You
> could also use bookmarks for the sites you use regularly enough that you
> know the TLD, so that you don't need a modifier key at all and can probably
> hit enter sooner (TBH, I suspect this is likely to be an improvement for
> your usecase). As I already said in comment #150, I don't think we'll bring
> back (an option to use) separate modifier keys for .net/.org. Marco, can you
> confirm?
This is still bad.

I all liked the 3 shortcuts. Bring them back. There was no reason to disable them.

[Bmorrison025 (bmorrison025)]

My Apple laptop has a Ctrl key on the left side only, which means this functionality is no longer a one-handed operation. For me this is a frustrating downgrade, but for others I expect it's an accessibility issue. No? I'd also like an option to restore the longstanding behavior.

[cousteau (cousteaulecommandant)]

I don't see how removing shift-enter and ctrl-shift-enter is even remotely related to the original request of making ctrl-enter open URLs in a new tab. In addition, it breaks a preexisting functionality of having shift-enter automatically add www. .net and ctrl-shift-enter add www. .org.
Personally, if this feature were really necessary (in which case it should have been opened as a separate bug), I would rather have it moved to an unused combination. For example, Windows-enter could be "open in new window" and Windows-alt-enter for "open in new tab, but on the background".
Or, if it is really that important to have these shortcuts on shift and ctrl-shift, even despite of breaking preexisting behavior and getting a lot of users upset, at least make windows-enter and ctrl-windows-enter the new .net and .org shortcuts so that this functionality is not lost.
(Or going further: use alt for .com, windows for .net, and alt-windows for .org, so that ctrl is left for opening on a new tab, be it from the URL bar or from a link on the page; now THAT would solve the inconsistency issue the bug originally complained about.)

Ultimately, removing the shortcut for .net and .org but keeping it for .com somehow suggests that .net and .org sites are "less important" than .com ones. I could expect that from a browser developed by google.com or microsoft.com, but not from one developed by mozilla.org.

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

(In reply to cousteau from comment #163)

> I don't see how removing shift-enter and ctrl-shift-enter is even remotely related to the original request of making ctrl-enter open URLs in a new tab.

The point of the bug as filed was to make link opening modifiers work the same between the url bar and other usecases. That applies to shift and ctrl-shift as much as it does to just ctrl.

> Personally, if this feature were really necessary (in which case it should have been opened as a separate bug), I would rather have it moved to an unused combination. For example, Windows-enter could be "open in new window" and Windows-alt-enter for "open in new tab, but on the background".

We don't use any windows+<whatever> shortcuts inside Firefox and doing so would be going against platform convention, which we wouldn't do without very good reasons, so this is a non-starter.

> Ultimately, removing the shortcut for .net and .org but keeping it for .com somehow suggests that .net and .org sites are "less important" than .com ones. I could expect that from a browser developed by google.com or microsoft.com, but not from one developed by mozilla.org.

In the global alexa top 50 there is 1 .org site (wikipedia), 1 .net site (a Chinese site), and 48 .com sites, and so .com sites are pretty conclusively more commonly used. Not to mention the fact that, if for whatever reason .net (or any other suffix) is more common in your own browsing habits, you can configure the default suffix in about:config (both before and after this change), and it was never possible to configure the suffix for shift-enter and ctrl-shift-enter.

I'm going to restrict comments here. The recent history of comments is just repeated complaints that reiterate ground that has already been covered, and as such isn't productive anymore. To reiterate:

- we won't (add a pref to) revert this behavior change. See comment #143. There are always trade-offs when making changes to frequently-used parts of the browser like the URL bar. We considered these trade-offs carefully before making the change. That doesn't mean we believe there are no negative side-effects, or that we don't regret people having to retrain muscle memory - it means we made the change despite those side-effects, because we believe the upsides outweigh those negative side-effects.
- yes, there's remaining ground to cover in terms of fixing up shortcuts to be even more consistent with other browsers and/or with other uses of modifier keys within Firefox. See bug 1513830, bug 1506203, bug 1506247 . If there's other inconsistencies that got missed, please file separate follow-up bugs.
- you can already change the default completion for ctrl-enter to something else in about:config using browser.fixup.alternate.suffix , if that's preferable over .com .
- there are extant bugs on file for improving webextension control over shortcuts via bug 1215061 and deps.