Closed Bug 237027 Opened 21 years ago Closed 6 years ago

Use ctrl-enter for URL canonization on all platform, and offer an opt-out ( browser.urlbar.ctrlCanonizesURLs ) for Windows/Linux users where it interferes with opening URLs in (background) tabs

Categories

(Firefox :: Keyboard Navigation, defect, P2)

Product:
Firefox
Component:
Keyboard Navigation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 64
Tracking Flags:
Tracking Status
relnote-firefox --- 64+
firefox64 --- fixed

People

(Reporter: mohr.42, Assigned: Gijs)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

(Keywords: uiwanted, user-doc-needed, ux-consistency, Whiteboard: ui-polish,[fxsearch])

Attachments

(5 files, 3 obsolete files)

Firefox extension to exchange Ctrl-Enter and Alt-Enter behaviour in the URL Bar (Update for FF >= 2.0)
(deleted), application/x-xpinstall
Details
preference to swap modifier keys
(deleted), patch
Gavin
: review-
Details | Diff | Splinter Review
simpler patch
(deleted), patch
Details | Diff | Splinter Review
Bug 237027 - Properly handle accel keys in address bar on macOS.
(deleted), text/x-review-board-request
Gijs
: review-
Details
Bug 237027 - allow turning off URL canonization, remove shift support, and move the remainder from 'cmd' to 'ctrl' on mac, r?mak
(deleted), text/x-phabricator-request
mak
: review+
Details
Firefox 0.8 i686 Linux If I want to open a new tab from the location bar, I hit Alt+Enter. If I have a link selected, I must hit Ctrl+Enter. It isn't intuitive to have Alt for one and Ctrl for the other.
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 we need to revisit this before 1.0. However, I think this is a dupe...
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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.
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).
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.
*** Bug 302492 has been marked as a duplicate of this bug. ***
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.
Whiteboard: ui-polish
Assignee: firefox → nobody
QA Contact: general
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
Attachment #205205 - Attachment is obsolete: true
(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.
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.
Another update of the mini extension to be usable for FF 2.*
Attachment #211147 - Attachment is obsolete: true
There are additional usability comments at https://bugs.launchpad.net/distros/ubuntu/+source/firefox/+bug/66566 Dave
(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.
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?
Keywords: uiwanted
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).
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.
Component: General → Keyboard Navigation
QA Contact: general → keyboard.navigation
Summary: inconsistent new tab shortcuts → Inconsistent new tab shortcuts (Alt+Enter in address bar but Ctrl+Enter for links)
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?
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...)
Flags: blocking-firefox3.1?
This will not block the final release of Firefox 3.1.
Flags: blocking-firefox3.1? → blocking-firefox3.1-
(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.
Attached patch preference to swap modifier keys (deleted) — — Splinter Review
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.
Attachment #385613 - Flags: review?
Attachment #385613 - Flags: review? → review-
Comment on attachment 385613 [details] [diff] [review] preference to swap modifier keys 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.
That sounds like this bug is supposed to be wontfix...
Since FF 3.5 unfortunately broke my own little extension (attachment 243585 [details]), 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
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.
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.*
Depends on: 469140
Rahul, would you have time to incorporate Gavin's comments for a new patch? It would be really appreciated.
Updating summary to reflect recently added duplicates like bug 513180.
Summary: Inconsistent new tab shortcuts (Alt+Enter in address bar but Ctrl+Enter for links) → Inconsistent new tab shortcuts (Alt+Enter in address bar but Ctrl+Enter for links; not working in search bar; browser.search.openintab broken)
Not sure why bug 513180 was duped here, but it looks entirely unrelated.
Summary: Inconsistent new tab shortcuts (Alt+Enter in address bar but Ctrl+Enter for links; not working in search bar; browser.search.openintab broken) → Inconsistent new tab shortcuts (Alt+Enter in address bar but Ctrl+Enter for links)
Gavin, thanks for correcting the summary and moving bug 513180 out of here. I slightly changed the summary again to reflect that the search bar's current /regular/ behaviour (ALT+Search->new tab) is also inconsistent with Ctrl+Link->new tab, because any truly consistent solution needs to consider/align all three of them: Links (incl. history/bookmarks), Location bar, Search bar. Cf. breakdown of current behaviour in comment #23.
Summary: Inconsistent new tab shortcuts (Alt+Enter in address bar but Ctrl+Enter for links) → Inconsistent "open in new tab" shortcuts (Ctrl+Enter for links, but Alt+Enter in address bar and search bar)
(In reply to comment #35) > Rahul, would you have time to incorporate Gavin's comments for a new patch? It > would be really appreciated. gavin rejected adding a preference, and i agree with him. so it's either WONTFIX, or change the default shortcuts. change them to what? if someone answers this, i'll write the patch for it.
(In reply to comment #39) > gavin rejected adding a preference, and i agree with him. so it's either > WONTFIX, or change the default shortcuts. change them to what? if someone > answers this, i'll write the patch for it. Alex, could you please check this bug?
(In reply to comment #39) > (In reply to comment #35) > > Rahul, would you have time to incorporate Gavin's comments for a new patch? It > > would be really appreciated. Unfortunately, Gavin's comments so far don't indicate a direction that a patch could take, other than that he doesn't want a pref for this. > gavin rejected adding a preference, and i agree with him. so it's either > WONTFIX, or change the default shortcuts. change them to what? if someone > answers this, i'll write the patch for it. Wontfix does not sound like a good idea for a bug that already has 11 votes and 6 duplicates. We'll get complaints about inconsistent shortcuts forever. To fix this, I think someone would first have to update the account of current behaviour as provided in comment #23. Some things have changed, e.g. in location bar, current behaviour is <alt>+enter for new tab (which is the main inconsistency this bug is about). Also, IE behaviour has changed, new tab modifier for links is now <ctrl> (like in FF). I think the concluding proposal of comment #23 is on the right track, but there is a logical error (probably typo) in the proposal for "in background" modifier key, which can't be the same as "new tab" modifier. So, without checking all the details, probably this would be a possible solution Proposal: "new Tab" Accelerator (default: [CTRL]) "new Window" Accelerator (default: [SHIFT]) "in Background" Accelerator (default: [SHIFT]) "auto Complete" Accelerator (default: [ALT]) "save as" Accelerator (default: [ALT]) 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 (Location and Search Bar only) [save as] + [ENTER] -> save link as (Links, History and Bookmarks only) (same behaviour for clicks instead of [ENTER]) I think we must be BETTER than IE and provide shortcuts that are consistent all over the place. Probably <ctrl> should be the consistent "new tab" modifier for all places: a) Accepting that "new tab" modifier should be consistent throughout the UI b) Accepting that "intelligent consistency" might be higher value than "IE compatibility" (we have the right and the claim to be better!) b) Noting that many people seem to expect <ctrl> to be the "new tab" modifier c) Assuming that <ctrl> tab is currently used most frequently as "new tab" modifier (both in IE and FF), because it's used with links d) Noting that FF currently uses <ctrl> as "new tab" modifier in the following places (when clicked; keyboard support for ctrl+enter is missing in some places and has its own bugs): - Links (!) - History (sidebar/menus/library) - Bookmarks (sidebar/menus/library) I'm aware I haven't covered all the details yet, this is just a starting point.
...alphabetical order should be consistent, too *sigh* (typo fix): Probably <ctrl> should be the consistent "new tab" modifier for all places: a) Accepting that "new tab" modifier should be consistent throughout the UI b) Accepting that "intelligent consistency" might be higher value than "IE compatibility" (we have the right and the claim to be better!) c) Noting that many people seem to expect <ctrl> to be the "new tab" modifier d) Assuming that <ctrl> tab is currently used most frequently as "new tab" modifier (both in IE and FF), because it's used with links e) Noting that FF currently uses <ctrl> as "new tab" modifier in the following places (when clicked; keyboard support for ctrl+enter is missing in some places and has its own bugs): - Links (!) - History (sidebar/menus/library) - Bookmarks (sidebar/menus/library)
I don't see opening from a link vs typed in address bar / search entry as inconsistent myself but as two different things. In any case you do not want to interfere with current use of Ctrl+Enter on Address bar. Complete .com Address Ctrl+Enter Complete .net Address Shift+Enter Complete .org Address Ctrl+Shift+Enter Nor would you want to interfere with getting loading tabs and bookmarks in background/foreground to be consistent - Bug 469456
Blocks: 565566
See Also: → https://launchpad.net/bugs/66566
In order to achieve consistent behaviour, I propose to fully drop this .com/.net/.org completion behaviour, since it has increasingly become obsolete: - there are only 4 additional chars to type - in a lot of countries/regions, this .com/.net/.org TLD trilogy does not really apply, or is at least overlaid with a local second-level-domain scheme. - users get nowadays[*] great support in URL completion by the awesomebar - there is nowadays[*] this search bar that lets you directly query your favourite search provider [*] compared to the old Netscape 4 days, when this .com/.net/.org completion has been conceived By the way, I'm wondering whether there are any Test Pilot usage statistics about the real usage numbers of [Ctrl-/Shift-/Ctrl-Shift-]Enter in the location bar... ?
Should block 565517, But I can't add it ;-)
Keywords: ux-consistency
That's for limi to decide, but we can certainly put this on the ux-consistency list.
upon reflection, i could write a simpler patch (no code complexity) that would keep the shortcuts consistent with explorer on pc but at least move them in to line with safari on mac. this seems like an improvement to the current state, regardless of what the end result will be.
Attached patch simpler patch (deleted) — — Splinter Review
ctrl = completion alt = new tab meta = new tab
Attachment #474603 - Flags: review?
Voting for sanity and simplicity: - ctrl - new tab - shift - new window - alt - save (in all cases; combinations for background opens etc) Advanced users can change the prefs or install add-ons. Using three key shortcuts is advanced IMO. I'm on Windows.
FYI, "Background Tabs" extension updated for 3.5 through 4.0b7... makes CTRL-click in URL bar and search bar open new tabs in background; in case it's useful to anyone: https://addons.mozilla.org/en-US/firefox/addon/13930/
Attachment #474603 - Flags: review?
Clearing old request on old patch. I'm going to close this bug, since it's unclear to me if this is still relevant on a modern Firefox. If it is, apologies, and please reopen with a concise description (and new patch? :) of what the modern issue is.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
I just tested Nightly, and nothing was ever fixed. Pressing Ctrl+Enter from the search bar still doesn't open the results in a new tab. Alt+Enter makes no sense, that's how you get Properties in Windows Explorer, or toggle full screen mode in a game.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Unfortunately fixing this at this point would be disastrous for muscle memory/user habits, so it's just not feasible.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 11 years ago
Resolution: --- → WONTFIX
Why not add a config option for this? Clearly this has been annoying users for years and will continue to do so.
Gavin is basically saying "this is how it's always been done, so this is how it will continue to be done". In the face of mounting evidence that this is not what everyone wants, seems like providing a flag is not too much to ask. Do the patches not provide an amenable compromise between "fixing" and providing a config for this? Please reconsider.
(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #56) > Unfortunately fixing this at this point would be disastrous for muscle > memory/user habits, so it's just not feasible. The problem with not fixing it is that the current behavior *is* atrocious for muscle memory/user habit, as (at least on Mac OS X, I can't speak for other OSes) currently, Firefox is the only browser that doesn't open a new tab when pressing Cmd+Return. This (and several other little things that are beyond the scope of this bug) makes it very hard for new users to switch to Firefox from e.g. Safari, where Cmd+Return means Open URL in a new tab (and, FWIW, Cmd+click means Open link in a new tab, Alt+Return means Download URL, and Alt+click means Download link.) I believe you should at the very least consider parity with other browsers / UX integration with the platform. This is a summary of the current behavior of the three main browsers on OS X: Browser | Cmd-Return | Alt-Return | Cmd-click | Alt-click Safari | Open in a new tab | [Download URL] | Open in a new tab | Download link Chrome(Chromium) | Open in a new tab | Open in a new tab | Open in a new tab | Download link Firefox | [Auto-completion] | Open in a new tab | Open in a new tab | [Nothing?]
This is WONTFIX. Your argument is invalid. No matter what you do, what facts or findings you present. WONT. FIX. EVER. (did you notice a decade passed since reporting this bug? A new generation of FF user came to existence since then! A DECADE!!!) So I recommend to lock this bug, so people don't waste their time in futile attempts to make some progress on it. Thank you.
So now there are two types of users: those who are annoyed by the current default and those who would be annoyed by any change in the current default. The usual way to deal with multiple differing user requirements is to add configuration knobs to support them. Why is that not a viable option?
We can't add configuration knobs to Firefox for everything that some subset of users want changed - we'd end up with hundreds or thousands of prefs, which makes maintaining Firefox harder, and it results in horribly confusing prefs UI if the prefs are exposed there (or dramatically reduces the pref's utility to users if they aren't). A change like this one could easily be accomplished using a Firefox add-on, though, so you always have a recourse when you don't like Firefox design decisions!
What about *both* ctrl- and alt-enter opening a new tab? (This is how Google Chrome behaves, presumably in order to accommodate FF users.) Currently ctrl-enter in the address bar has no different effect than enter by itself, so this change would satisfy both parties.
No fix in Firefox 29 for Mac. In address bar, pressing Command + Enter doesn't open in new tab. This is inconsistent with most other browsers on Mac.
(In reply to mghostsoft from comment #64) > No fix in Firefox 29 for Mac. In address bar, pressing Command + Enter > doesn't open in new tab. This is inconsistent with most other browsers on > Mac. +1
(In reply to lowcactus3s from comment #65) > (In reply to mghostsoft from comment #64) > > No fix in Firefox 29 for Mac. In address bar, pressing Command + Enter > > doesn't open in new tab. This is inconsistent with most other browsers on > > Mac. > > +1 Another +1. Cmd+return is the default behavior for both Safari and Chrome on OSX.
Gavin, Please reconsider this issue. Allowing both ctrl- and alt-enter opening a new tab would accommodate all concerns and reservations expressed in this thread. Currently ctrl-enter in the address bar has no different effect than enter by itself, so this change would satisfy all parties.
Are there any currently-working add-ons that alleviate this bug? The add-ons mentioned here no longer work as far as I can tell. Thanks
semi-annual post to confirm that this bug persists into latest release, and this behavior still doesn't make sense.
(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #56) > Unfortunately fixing this at this point would be disastrous for muscle > memory/user habits, so it's just not feasible. This bug still seems to be annoying people. Philipp, do you agree that the current behavior of accel+enter (adding www. and .com, and loading in the current tab) has been here for so long that we can't fix it at this point? Or given that this behavior was introduced to mimic IE's behavior, would it be reasonable to implement "accel+enter opens in new tab" for OS X only, where no other browser has ever supported the www./.com completion behavior?
Flags: needinfo?(philipp)
Probably just an about:config option would be enough to fix this for people who want the old behaviour back.
Hi all, the extension background tabs works for that purpose. It's also extra useful because it opens the url you put in in a new background tab. If you want to open it and also focus you can use ctrl+t.
I just installed the extension "Background Tabs", and it does just what I wanted (though I've only used it a few times, so far). Thanks to Alexander for pointing this out. However, I don't think this extension is a general solution for this issue, because it requires knowing how to use add-ons, and success in finding this one. I had searched for such an add-on, and had failed to find this one. To make Firefox more intuitive, I still think a good approach would be to make the behavior of control-click or control-enter in the address bar be with consistent those key strokes on the page (opening a URL in a new tab). For users wanting those keystrokes to do the same thing as in IE, provide them with an extension or about:config option to do that. IE has inconsistent behavior with its shortcut keys: control-enter on a selected link on a page opens the page in a new tab; the same key strokes in the address bar open a URL in the current tab. No need for Firefox to also be inconsistent.
Hi Christopher, I kinda agree. However the change may be confusing for users who use the ctrl+enter to add .com. What is your suggestion for that shortcut? Swap it with alt+enter? Also, the current "open in new tab" doesn't really make sense to me. If one wants to immediately switch to that tab, one can also just use ctrl+t. Maybe then change that behaviour to "open in new background tab" just like the extension does? But this may be out of the scope for this issue. Kind regards
> "Also, the current "open in new tab" doesn't really make sense to me." For me, there are several use cases in my muscle memory for Chrome: e.g. * slight change to existing URL "https://bugzilla.mozilla.org/show_bug.cgi?id=237027" to "https://bugzilla.mozilla.org/show_bug.cgi?id=12345" * open a bunch of variants quickly: "example.com/long-annoying-paginated-url?page=1", "example.com/long-annoying-paginated-url?page=2", "example.com/long-annoying-paginated-url?page=3" etc. -- many fewer keystrokes than copy, new tab, paste, then edit, then switch back to original tab and repeat. * reload the same page in a background tab
Hi Aaron, muscle memory is a reasonable point to me. However you could say the same about the people who muscle memorized the current function maybe. Your three listed points all look legit to me. For all of them, opening in new *background* tab instead of new tab in focus is actually a better option I suppose. Especially your last point > * reload the same page in a background tab As it is right now you'd have to wait for the site to finish loading up (or switch back to your other tab). Kind regards
Yes, fair point. I'm not saying that my muscle memory should take precedence. I think the points about internally consistent behavior and matching behavior of other browsers are more compelling. Maybe upon hitting cmd-enter, FF could detect whether the entry was in need of .com completion, and perform whatever action accordingly. There is some logic in place already to determine whether or not to append ".com": when i enter mozilla.org and hit cmd-enter, my request isn't transformed to mozilla.org.com
Change puts a burden on current users. But if the new way is better, lets change. I remember when the ribbon replace menus in Microsoft Office. The change meant extra work for those of us used to the old behavior. However, it looked to me like a couple of people who were not good at computers were able to learn to use the ribbon more easily than they had used the menus. I believe the ribbon is better than the menus, and was worth having to learn.
Yes, it's true that any change has the potential to interrupt current users. But, if FF could detect when to append ".com" vs. when to open a new tab based on the entered URL, then this is a very minimal change for current users. The current behavior of ".com-completion in same tab, when applicable" could remain in place. The only behavior that's actually needs to change is from the existing "cmd-enter does nothing" to "cmd-enter opens in new tab" when .com-completion is not applicable. Furthermore, with the proliferation of TLDs, it seems like .com-completion has become less useful. Adding a config to change this behavior doesn't seem like an unreasonable approach either.
As a lowly user (not dev), please can we have some kind of option regarding ALT+ENTER behaviour? And to summarise my following comments, options for behaviour for CTRL+ENTER too? It could be just set in about:config, depending on how popular the alternative behaviours are. For example, CTRL+ENTER autocomplete vs open address in new tab. I personally don't use ALT+ENTER for generating a URL in a new tab. In fact, I can't explain why but I've only just noticed its new tab behaviour literally today. For example, I use tab mix plus to generate duplicate pages with history when I need a new tab (using CTRL+T), except with links, when CTRL+mouseclick works very nicely. I do appreciate that users develop habits and look for flexibility in usage between keyboard and mouse actions, so if ALT+ENTER is good for someone, then that's what they like and why should they change. Having said that, I haven't ever used ALT+ENTER for that functionality. I actually use ALT+ENTER with an extension called URL suffix (lovely, practical add-on IMO), which allows additional keystroke combos (beyond CTRL+ENTER) to generate additional URL prefixes & suffixes. I've configured ALT+ENTER to add a www. and .co.uk to a URL. This 'open address in a new tab' honestly never used to occur (for me), so I sense something may have changed or has been updated in firefox, relatively recently, given I do use these keyboard shortcuts for autocompletion. I've found some references to loss of this behaviour when using tab mix plus. Most posts are ancient but there was an isolated report in Nov 2015, involving a beta of FF 43. Anyway, ALT+ENTER and firefox led me here. I do agree with one contributor that one can't just bung in an option every time there's a conflict but when one's talking about keystrokes (both ALT+ENTER and CTRL+ENTER) which directly affect daily tasks/usability, perhaps there's an argument for considering support for alternatives. Standardisation is generally speaking good but we've got usage differences across browsers and platforms, which I can't see being harmonised easily and, depending on the solution, I would have thought we're not talking about much in the way of code changes, if we just added some choices in about:config. Sorry if I'm talking nonsense though - I'm not a coder. Regards, Gary
Seeing that both Chrome and Safari are using Cmd/Ctrl-Enter for opening something in a new background tab AND that this is also consistent with our use of Cmd/Ctrl in other contexts, I would support changing it. Re-opening on that basis. As far as priority goes, this is obviously on the lower end though...
Status: RESOLVED → REOPENED
Flags: needinfo?(philipp)
Resolution: WONTFIX → ---
Comment on attachment 8818332 [details] Bug 237027 - Properly handle accel keys in address bar on macOS. https://reviewboard.mozilla.org/r/98432/#review98694 Seems to me from comment 81 that this change should not be OS X - specific.
Attachment #8818332 - Flags: review?(gijskruitbosch+bugs) → review-
(In reply to :Gijs Kruitbosch from comment #83) > Seems to me from comment 81 that this change should not be OS X - specific. So do you think we should remove the maybeCanonizeURL code altogether? I wasn't sure if we wanted to keep this behavior inherited from Internet Explorer on at least Windows, so I suggested making the minimal behavior change for a first patch (I was helping nox understand how this code works while we were waiting at the airport).
(In reply to Florian Quèze [:florian] [:flo] from comment #84) > (In reply to :Gijs Kruitbosch from comment #83) > > > Seems to me from comment 81 that this change should not be OS X - specific. > > So do you think we should remove the maybeCanonizeURL code altogether? I > wasn't sure if we wanted to keep this behavior inherited from Internet > Explorer on at least Windows, so I suggested making the minimal behavior > change for a first patch (I was helping nox understand how this code works > while we were waiting at the airport). I'm not familiar with the pedigree of maybeCanonizeURL. It looks like the functionality was originally introduced in 2002 by Hyatt with no bug number. It does look like IE still does this type of completion. Philipp, what do you want to do? (note that "keep matching IE on Windows" != "only change this on OS X"; we should specialcase Windows, not OS X)
Flags: needinfo?(philipp)
Also, if we're going to change this on only some platforms, given the contention, the most straightforward thing would be to have a pref that we default to different values on Windows - then Windows users who don't care for the IE behaviour can flip it, or vice versa.
:Gijs I don't understand what you mean about a pref on Windows if we only change this "on only some platforms", given that platform would be macOS where that behaviour is the odd one. Why do a pref?
(In reply to Anthony Ramine [:nox] from comment #87) > :Gijs I don't understand what you mean about a pref on Windows if we only > change this "on only some platforms", given that platform would be macOS > where that behaviour is the odd one. Why do a pref? As I understand comment #84, if we keep this behaviour (ctrl-enter completing to www.<whatever>.com) at all, it'll be on Windows only. I don't see how macOS is special - Windows is, and Linux and macOS should get the 'open in a new tab' behaviour. What I'm saying is that whether we use the existing canonizeURL behaviour should go be behind a pref that's true on Windows and false everywhere else (ifdef'd in all.js).
(but all that is subject to what Philipp says - he reopened the bug in comment #81 so it's up to him to clarify.)
(In reply to :Gijs Kruitbosch from comment #86) > Also, if we're going to change this on only some platforms, given the > contention, the most straightforward thing would be to have a pref that we > default to different values on Windows - then Windows users who don't care > for the IE behaviour can flip it, or vice versa. A pref would make sense, especially if we want to be able to test both behaviors on all platforms. I didn't suggest it mostly because of comment 62, but that comment was arguably more about exposing the pref in the UI than about having a pref in the implementation.
(In reply to Florian Quèze [:florian] [:flo] from comment #90) > (In reply to :Gijs Kruitbosch from comment #86) > > Also, if we're going to change this on only some platforms, given the > > contention, the most straightforward thing would be to have a pref that we > > default to different values on Windows - then Windows users who don't care > > for the IE behaviour can flip it, or vice versa. > > A pref would make sense, especially if we want to be able to test both > behaviors on all platforms. I didn't suggest it mostly because of comment > 62, but that comment was arguably more about exposing the pref in the UI > than about having a pref in the implementation. Yeah - I don't think we want UI, but if we're going to do different things per-OS we might as well implement-via-hidden-pref than hardcode the OS distinctions. There's plenty of precedent for that, e.g. backspace-for-history.back being a hidden pref (browser.backspace_action) that's different on Linux vs. elsewhere.
Maybe we could telemetry the usage of the canonize feature, while we are at it. Though, it's likely something that falls into the "pretty much unused cause it's undiscoverable, but will have a vocal minority of fans", so not sure if it's worth it. FWIW, Edge still support CTRL+Enter, but doesn't add www. anymore, only .com. Maybe we should do the same for consistency if the feature is intended as an help for users migrating from IE/Edge to Firefox.
OK, so it looks like Edge, IE, Chrome and Firefox on Windows all currently do a version of autocompleting to www.$query.com on Ctrl-Enter. So I agree that doing this per-OS makes sense, since macOS seems to lean more heavily towards interpreting Cmd-something as doing things in a new tab.
Flags: needinfo?(philipp)
Whiteboard: ui-polish → ui-polish,[fxsearch]
Priority: -- → P2
(In reply to Anthony Ramine [:nox] from comment #95) > What should I do to get this fixed? Your patch does: > } else if (this.AppConstants.platform == "macosx") { and > this.AppConstants.platform == "macosx") { It also hardcodes 'accel' to always mean 'ctrl'. Instead, leave the accel handling as-is, don't check for the OS, but add a preference line in all.js, e.g. for "browser.urlbar.accelenter.newtab". Use #ifdefs for that pref and, on Windows, set it to false, and on everything else, to true. Then instead of checking the OS in your patch, check the preference, and use that to decide what to do.
(In reply to :Gijs from comment #96) > add a preference line in all.js Err, might need to be in firefox.js - check where the other urlbar behaviour prefs live. :-)
"Cmd+Enter" not opening a new tab from the address bar has been my biggest hangup as I attempt to switch from Chrome to Firefox now.
Hello, can we have alt+return open the page in the background? It's useful when you want to do something later. If you want to focus the page immediately, like Firefox does right now for alt+return, you can just use ctrl+t so I don't understand why alt+return opens in foreground too since there is already ctrl+t for that. Before there was the extension background tabs but there is no Webextension version of that. Thanks for reading
> "Cmd+Enter" not opening a new tab from the address bar has been my biggest hangup as I attempt to switch from Chrome to Firefox now. Current Behaviour 1. On Links on a page - Command + Click - Opens up on new tab (As expected) 2. On Browser Back and Forward button - Command + Click - Opens up in new tab (As expected) 3. On Address Bar - Command + Enter - Reloads in the same page (Unexpected, should Open in new page) For now, I do Option+Enter, but is inconsistent with the rest of the behaviour.
(In reply to :Gijs (he/him) from comment #96) > (In reply to Anthony Ramine [:nox] from comment #95) Was this hidden preference ever implemented? Is there an undocumented way to change this behavior? On MacOs, Chrome and Safari both open a new tab on Cmd+Enter. Maintaining an IE behavior on a Mac seems counter-intuitive.
This isn't convention on macOS or other *nix platforms. Even on Windows, some people may prefer a different behavior.
I made a small sheet to better understand what changes here, please check and comment if something doesn't look correct. https://docs.google.com/spreadsheets/d/1VVEVjyIYRZIFteM71j5bJhENa2xXT82gaikr0WgpKLA/edit#gid=0 I didn't test the patch, I just assumed, on IRC Gijs said it's likely different. Anyway, I added a row with the behavior I'm suggesting, that is pretty much the same as Chromium, apart ALT+Enter on the Mac.
(In reply to Marco Bonardo [::mak] (Away 9-26 Aug) from comment #103) > I made a small sheet to better understand what changes here, please check > and comment if something doesn't look correct. > https://docs.google.com/spreadsheets/d/ > 1VVEVjyIYRZIFteM71j5bJhENa2xXT82gaikr0WgpKLA/edit#gid=0 > > I didn't test the patch, I just assumed, on IRC Gijs said it's likely > different. > Anyway, I added a row with the behavior I'm suggesting, that is pretty much > the same as Chromium, apart ALT+Enter on the Mac. I think I implemented this in the updated patch, though I left out the support for downloads using 'alt-enter' on mac. I'm not convinced people want that behaviour, and in any case it'd re-introduce per-platform checks and some redundant calls to whereToOpenLink that I'm not super-fond of. Note that the spreadsheet doesn't cover shift-enter, which also canonifies today. I left that as-is, though of course that now also comes under the pref, and can therefore be turned off (at which point we'll open a new window instead).
(In reply to :Gijs (Not available 3-19 Aug; he/him) from comment #104) >> Note that the spreadsheet doesn't cover shift-enter, which also canonifies > today. I left that as-is, though of course that now also comes under the > pref, and can therefore be turned off (at which point we'll open a new > window instead). Ah, I didn't remember shift, why are we doing that exactly? it sounds wrong. Nor Edge nor Chrome do that, so it's not a parity reason. And I can see why they don't, it's trivial to leave your finger on shift when typing text and then we'd try to canonize it. Additionally we also use shift for tab VS tabshifted, so this is just adding confusion. May we file a bug to stop supporting shift and relegate canonize to just CTRL? provided we don't want to do that here.
So, we apparently do: ctrl => .com shift => .net ctrl + shift => .org First, I'm not convinced .net and .org are more important than the other many tlds around, for example in a localized build it would be far more interesting to canonize to the local tld (for example .it for italian). I'd totally support ctrl+shift to complete to the localized tld rather than .org (though this would require localization support). Second, I'd like if ctrl would be the necessary key to activate canonization in general, so all the shortcuts should required ctrl to be pressed. Shift is far too common when typing and as I said it's already used by tab/tabshifted, it's just confusing. I understand changing this we could break muscle memory of a minority, but it's for a totally undiscoverable feature on less critical tlds than .com. and we're changing cmd on Mac already, for which we'll want a relnote. I'd honestly propose to drop the shift and ctrl+shift behaviors completely.
And, we could make canonize complete to browser.fixup.alternate.prefix and browser.fixup.alternate.suffix, so the user can adapt it to his needs.
Does this still cover the original intention of this bug and several duplicates that users want an option (ideally on by default) where Ctrl+Enter in location bar opens the address in a new tab? It's confusing that sometimes we need to press Ctrl and sometimes Alt to open things in a new tab. Why can't we just make ALT the default canonizer shortcut key? Otherwise allow user to switch canonization off and have Ctrl+Enter = open in new tab behaviour instead.
(In reply to Marco Bonardo [::mak] (Away 9-26 Aug) from comment #103) > I made a small sheet to better understand what changes here, please check > and comment if something doesn't look correct. > https://docs.google.com/spreadsheets/d/ > 1VVEVjyIYRZIFteM71j5bJhENa2xXT82gaikr0WgpKLA/edit#gid=0 > > I didn't test the patch, I just assumed, on IRC Gijs said it's likely > different. > Anyway, I added a row with the behavior I'm suggesting, that is pretty much > the same as Chromium, apart ALT+Enter on the Mac. Unfortunately, I failed to access that table. Can you make it public?
It's now public, cheers.
(In reply to Thomas D. (currently busy elsewhere) from comment #108) > Does this still cover the original intention of this bug and several > duplicates that users want an option (ideally on by default) where > Ctrl+Enter in location bar opens the address in a new tab? It's confusing > that sometimes we need to press Ctrl and sometimes Alt to open things in a > new tab. It should, yes. Overall the idea is that CTRL will be the canonization key, and it should be possible to disable it, as well as it should imo be possible to set what to canonize to (if one prefers .it to .com, for example). Then on Mac, CMD will open in a new tab, rather trying to canonize. > Why can't we just make ALT the default canonizer shortcut key? It would not be coherent with any other browser, and we want users to feel home when then move to Firefox. All of the other browsers canonize on CTRL.
Assignee: nobody → gijskruitbosch+bugs
Status: REOPENED → ASSIGNED
(In reply to Marco Bonardo [::mak] from comment #107) > And, we could make canonize complete to browser.fixup.alternate.prefix and > browser.fixup.alternate.suffix, so the user can adapt it to his needs. We already use .suffix, see https://searchfox.org/mozilla-central/rev/c3fef66a5b211ea8038c1c132706d02db408093a/browser/base/content/urlbarBindings.xml#1048-1055 . I think using prefix can be a follow-up bug, that doesn't seem super valuable to me (in fact, I would prefer to get rid of the alternate stuff as it's currently needlessly being mixed in with other bits of URL fixup in nsDefaultURIFixup, but that's a separate discussion). I'll remove shift support here because it affects the pref name, and adding a pref and then renaming it immediately seems stupid. Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=aad17bf2c7fa4acaf46e1d71cf79069d192d5ecd
(In reply to Marco Bonardo [::mak] from comment #111) > It should, yes. Overall the idea is that CTRL will be the canonization key, > and it should be possible to disable it, as well as it should imo be > possible to set what to canonize to (if one prefers .it to .com, for > example). > Then on Mac, CMD will open in a new tab, rather trying to canonize. Will this finally work with the normal find bar an not just the quickfind bar?
(In reply to avada from comment #113) > (In reply to Marco Bonardo [::mak] from comment #111) > > It should, yes. Overall the idea is that CTRL will be the canonization key, > > and it should be possible to disable it, as well as it should imo be > > possible to set what to canonize to (if one prefers .it to .com, for > > example). > > Then on Mac, CMD will open in a new tab, rather trying to canonize. > > Will this finally work with the normal find bar an not just the quickfind > bar? I don't understand - this bug has nothing to do with the find bar, it's about the location bar. The 'search bar' in the summary is about the bar that searches on your default search engine (e.g. duckduckgo, google, bing, ...), not the find-in-page feature. Did you mean to comment on a different bug?
Attachment #8996717 - Attachment description: Bug 237027 - allow turning off URL canonization, and turn it off on Linux and Mac, r?mak → Bug 237027 - allow turning off URL canonization, remove shift support, and move the remainder from 'cmd' to 'ctrl' on mac, r?mak
Comment on attachment 8996717 [details] Bug 237027 - allow turning off URL canonization, remove shift support, and move the remainder from 'cmd' to 'ctrl' on mac, r?mak Marco Bonardo [::mak] has approved the revision.
Attachment #8996717 - Flags: review+
Pushed by gijskruitbosch@gmail.com: https://hg.mozilla.org/integration/autoland/rev/6b31860ce710 allow turning off URL canonization, remove shift support, and move the remainder from 'cmd' to 'ctrl' on mac, r=mak
(In reply to :Gijs (he/him) from comment #114) > (In reply to avada from comment #113) > > (In reply to Marco Bonardo [::mak] from comment #111) > > > It should, yes. Overall the idea is that CTRL will be the canonization key, > > > and it should be possible to disable it, as well as it should imo be > > > possible to set what to canonize to (if one prefers .it to .com, for > > > example). > > > Then on Mac, CMD will open in a new tab, rather trying to canonize. > > > > Will this finally work with the normal find bar an not just the quickfind > > bar? > > I don't understand - this bug has nothing to do with the find bar, it's > about the location bar. The 'search bar' in the summary is about the bar > that searches on your default search engine (e.g. duckduckgo, google, bing, > ...), not the find-in-page feature. Did you mean to comment on a different > bug? Not at all. With the quickfind bar you can press enter to open a link, or press ctrl+enter to open it in a new tab. But you can not do this with the normal findbar.
(In reply to avada from comment #118) > Not at all. With the quickfind bar you can press enter to open a link, or > press ctrl+enter to open it in a new tab. But you can not do this with the > normal findbar. That is not relevant to this bug, which is about the location bar and the web search bar and what happens if you press ctrl-enter in that. Those don't share any code with the find bar, so any changes there would have to be a different bug, in a different component, and affecting different code. Your suggestion was discussed in bug 1232096 and wontfixed there. This bug is not related and therefore not the right place to ask for reconsideration.
https://hg.mozilla.org/mozilla-central/rev/6b31860ce710
Status: ASSIGNED → RESOLVED
Closed: 11 years ago → 6 years ago
status-firefox64: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
(In reply to Marco Bonardo [::mak] from comment #106) > So, we apparently do: > ctrl => .com > shift => .net > ctrl + shift => .org > > First, I'm not convinced .net and .org are more important than the other > many tlds around, for example in a localized build it would be far more > interesting to canonize to the local tld (for example .it for italian). I'd > totally support ctrl+shift to complete to the localized tld rather than .org > (though this would require localization support). > Second, I'd like if ctrl would be the necessary key to activate canonization > in general, so all the shortcuts should required ctrl to be pressed. Shift > is far too common when typing and as I said it's already used by > tab/tabshifted, it's just confusing. > I understand changing this we could break muscle memory of a minority, but > it's for a totally undiscoverable feature on less critical tlds than .com. > and we're changing cmd on Mac already, for which we'll want a relnote. > I'd honestly propose to drop the shift and ctrl+shift behaviors completely. Color me surprised when I updated to Nightly 64.0 and found out that the keyboard shortcuts that I've relied on Firefox having for the past 15 years apparently requires some rewiring of muscle memory. This change does make sense and does indeed make it more consistent all around -- but will definitely catch A LOT of long-time macOS Firefox users off-guard if not announced gracefully. This goes the same for keybord-shortcut aficionados/ power users. It will also require documentation updates (i.e. https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly#w_miscellaneous_2 and https://blog.mozilla.org/firefox/keyboard-shortcuts-command-qwerty/) since this is literally 15 year old behavior that is changing. It's also been blogged about over the years throughout various websites that cater to the power user (such as LifeHacker and How-To-Geek), but that's nothing that Mozilla controls. That being said, can we get about:config options to configure the Ctrl-Shift and Shift-Enter shortcuts in the address bar? When this feature was first added, .com, .net. and .org were the most popular of TLD suffixes. Today, I can see how that is different, and I will admit that I do not complete .net and .org domains as often. I agree that not many people used it, but perhaps it can be more accessible if a user can configure those prefixes and suffixes directly.
Release Note Request (optional, but appreciated) [Why is this notable]: see comment #121 [Affects Firefox for Android]: no [Suggested wording]: not sure, maybe: "Changes to URL bar autocomplete shortcuts" [Links (documentation, blog post, etc)]: I'll update https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly#w_miscellaneous_2 . (In reply to Stanley Chan from comment #121) > It will also require documentation updates (i.e. > https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox- > tasks-quickly#w_miscellaneous_2 and I'll submit an update for this after submitting this comment; it'll need to be approved by the SUMO admins. > https://blog.mozilla.org/firefox/keyboard-shortcuts-command-qwerty/) I'll set user-doc-needed here for the above and to get this updated as well. > this is literally 15 year old behavior that is changing. It's also been > blogged about over the years throughout various websites that cater to the > power user (such as LifeHacker and How-To-Geek), but that's nothing that > Mozilla controls. No, I'm afraid if we could never update something that had been documented anywhere else, we would have long ago stopped making Firefox because of our inability to change pretty much anything... even our easter eggs get documented, for better and for worse... > That being said, can we get about:config options to configure the Ctrl-Shift > and Shift-Enter shortcuts in the address bar? There is already for the ctrl-enter case (you can change the suffix via about:config's browser.fixup.alternate.suffix). We removed the shift/ctrl-shift option completely because no other browser has those and they didn't seem useful. > When this feature was first > added, .com, .net. and .org were the most popular of TLD suffixes. Today, I > can see how that is different, and I will admit that I do not complete .net > and .org domains as often. I agree that not many people used it, but perhaps > it can be more accessible if a user can configure those prefixes and > suffixes directly. I see your point, but can I just point out that: - shift-click/enter normally opens new windows on all other types of shortcuts / bookmark/history entries etc. - shift-click/enter is also used for "turning off" switch-to-tab (in order to open links that you have open already a second time) - shift when used with opening new tabs in other places (which uses 'ctrl' on Win/Linux) toggles the background/foreground-ness of tabs so having Yet Another Possible Meaning for the 'shift' modifier here is neither very user-friendly nor all that maintainable in the codebase we have. In fact, even removing it caused me a few different headaches trying to not break any of the other behaviors. The other thing is the value proposition. You'd want this shortcut to avoid typing '.' followed by 2-3 other characters (generally... if you use loads of different '.americanexpress' domains and want to configure ctrl-shift-enter for those, then I'm very sorry...). Just the awkwardness of `ctrl-shift-enter` rather than simply typing those 3-4 chars doesn't seem very valuable to me. That's in addition to the fact that, 15 years since this stuff was implemented, we now autofill history for domains, so if you've visited the site before you can just hit 'enter' straightaway anyway... We're also much more reluctant to add more magical about:config switches that we don't expose in the "regular" options/preferences (and yet more reluctant to add *more* things to those options). So on the whole, I'm not excited about adding this back, not even with configurable suffixes. If my arguments don't seem convincing, please file a separate bug and we'll discuss there, but with 121 comments here so far, I don't think this is the best place. :-)
relnote-firefox: --- → ?
Keywords: user-doc-needed
Hey all, I think opening a new tab in background in a fast way/without leaving the current page is very useful. I had an extension for that but it's no longer possible because webext API does not offer that possibility. That's why I'm following this bug closely. However now I'm surprised. Here are all the things that happen on Firefox nightly 64.0a1 (2018-09-06) (64-Bit): ctrl: add www..com ctrl shift: www.com (should be add www..com in new window?) shift: new window foreground alt: new tab foreground alt ctrl: add www..com and open in new tab foreground alt shift: nothing happens, should be default action in tab background or new window background? alt shift ctrl: www.com new tab background The name/description of this bug is "Inconsistent "open in new tab" shortcuts (Ctrl+Enter for links, but Alt+Enter in address bar and search bar)" So I think the changes now are useful, but do they solve the original issue? Ctrl+Enter still doesn't open a new tab in background, like it does everywhere else. I suggest: ctrl: open in new tab in background shift: open in new window in foreground alt: Doesn't matter to me, maybe add www..com so people who want it still have it or keep it as new tab in foreground (but what's the advantage of that? just hit ctrl+t) ctrl shift: open in new window in background alt shift: like alt but in new window in foreground alt ctrl: like alt but in new background tab alt shift ctrl: like alt but in new window in background What do you think? Sorry, I don't want to stand in the way of closing this or marking it as fixed, but it doesn't seem to address the original point to me. Anyway thanks for the changes and reading this.
(In reply to alexander.kern from comment #123) > Hey all, I think opening a new tab in background in a fast way/without > leaving the current page is very useful. I had an extension for that but > it's no longer possible because webext API does not offer that possibility. Not from the URL bar, but extensions can definitely open background tabs, so an add-on could still do this using a page/browser action or a sidebar to offer you UI. > That's why I'm following this bug closely. However now I'm surprised. Here > are all the things that happen on Firefox nightly 64.0a1 (2018-09-06) > (64-Bit): > > ctrl: add www..com > ctrl shift: www.com (should be add www..com in new window?) > shift: new window foreground > alt: new tab foreground > alt ctrl: add www..com and open in new tab foreground > alt shift: nothing happens, should be default action in tab background or > new window background? > alt shift ctrl: www.com new tab background > > The name/description of this bug is "Inconsistent "open in new tab" > shortcuts (Ctrl+Enter for links, but Alt+Enter in address bar and search > bar)" > > So I think the changes now are useful, but do they solve the original issue? > Ctrl+Enter still doesn't open a new tab in background, like it does > everywhere else. I suggest: > > ctrl: open in new tab in background This behavior is now possible, but it's behind a pref (about:config, browser.urlbar.ctrlCanonizesURLs), because the outcome of some of the (long) discussion here was that to remain consistent with Chrome and IE/Edge, we would continue to keep that as the default (see e.g. comment #93). Note that AFAIK Chrome uses `ctrl-enter` even on Linux and Mac, so per the spreadsheet in comment #103 ( https://docs.google.com/spreadsheets/d/1VVEVjyIYRZIFteM71j5bJhENa2xXT82gaikr0WgpKLA/edit#gid=0 ) the default there is also to use ctrl-enter. (This is a change on mac, where it used to be cmd-enter.) I'll change the summary to more accurately reflect what was changed here.
Summary: Inconsistent "open in new tab" shortcuts (Ctrl+Enter for links, but Alt+Enter in address bar and search bar) → Use ctrl-enter for URL canonization on all platform, and offer an opt-out for Windows/Linux users where it interferes with opening URLs in (background) tabs
(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!
(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. :-)
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?)
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?
(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.
Flags: needinfo?(alexander.kern)
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!
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
QA Whiteboard: [bugday-20180926]
Blocks: 1496981
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
relnote-firefox: ? → 64+
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.
Flags: needinfo?(alexander.kern)
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.
(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.
Summary: Use ctrl-enter for URL canonization on all platform, and offer an opt-out for Windows/Linux users where it interferes with opening URLs in (background) tabs → Use ctrl-enter for URL canonization on all platform, and offer an opt-out ( browser.urlbar.ctrlCanonizesURLs ) for Windows/Linux users where it interferes with opening URLs in (background) tabs
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.
(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.
(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.
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!
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?
(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.
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
Blocks: 1513830
(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.
(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.
Depends on: 1506203
(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.
Depends on: 1506247
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?
(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.
(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.
(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
> 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.
(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.
(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?
(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?
Flags: needinfo?(mak77)
Depends on: 1515585
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.
(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.
Flags: needinfo?(mak77)
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

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.

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

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.

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

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.

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.

(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.
Status: RESOLVED → VERIFIED
Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: