Closed
Bug 1116565
Opened 10 years ago
Closed 3 years ago
On a link, Ctrl-click opens background tab, Ctrl+Shift+click foreground; while the opposite happens with the bookmarks toolbar
Categories
(Firefox :: Bookmarks & History, defect, P3)
Tracking
()
RESOLVED
DUPLICATE
of bug 469456
People
(Reporter: chris, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: parity-chrome, parity-edge)
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141126041045
Steps to reproduce:
If I Ctrl-click on a link in a Web page it opens a new tab but doesn't switch to that tab. If I Ctrl-Shift-click on a link in a Web page, it opens a new tab and switches to that tab. This is the behavior I would expect and matches what other browsers do. However, using these modified clicks in the Bookmarks Toolbar produces the opposite effect: If I Ctrl-click a bookmark, it opens a new tab and switches to that tab. If I Ctrl-Shift-click a bookmark, it opens a new tab but does not switch to that tab.
Actual results:
See above.
Expected results:
Ctrl-click and Ctrl-Shift-click in the Bookmarks Toolbar should produce the same behavior as using these clicks in a Web page.
Reporter | ||
Comment 1•10 years ago
|
||
I should add, this "opposite" behavior that happens with bookmarks also happens with the right-click context menu. For example, if I right-click on an image in a Web page and then Ctrl-click "View Image" in the context menu, it will open the image in a new tab and switch to that tab. If I Ctrl-Shift-click "View Image," it will open the image in a new tab but does not switch to that tab. Again, this is the opposite of what should happen.
Comment 2•10 years ago
|
||
Confirmed with 2014-12-30-03-02-14-mozilla-central-firefox-37.0a1.ru.linux-x86_64.
Couldn't find a duplicate, but a few WFM or NEW bugs asked for the "more popular" behaviour for various things.
However, what I see could be the default setting for the Linux Firefox.
It is controlled by browser.tabs.loadInBackground pref, which is "true" here. Please enter about:config in the address bar, enter browser.tabs.loadInBackground in the field, and check if you have true or false there, and if it is the default or not.
Flags: needinfo?(chris)
OS: Windows 8.1 → All
Summary: Ctrl-Click Anomalies → On a link, Ctrl-click opens background tab, Ctrl+Shift+click foreground; while the opposite happens with image context menu and bookmark toolbar
Comment 3•10 years ago
|
||
I can reproduce this on OS X with cmd/cmd-shift as well, with loadInBackground the default (true), and as best I can tell that is the default everywhere.
Seems to me the behaviour should be consistent as suggested by the reporter, and possibly inverted (everywhere) based on the pref, if the user flips it. Dão, Marco, please comment if there is history / intent here that I am missing...
Status: UNCONFIRMED → NEW
Component: Untriaged → General
Ever confirmed: true
Flags: needinfo?(chris) → firefox-backlog+
Comment 4•10 years ago
|
||
The intent of loading tabs in the background when activating a link with Ctrl+click or the middle mouse button is to make it easy to open a link for later while staying on the current page to continue reading that for the time being, possible open more foreground tabs etc.. The same use case hardly exists for bookmarks and other stuff like "View Image", and therefore the defaults are different.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: firefox-backlog+
Resolution: --- → INVALID
Reporter | ||
Comment 5•10 years ago
|
||
Dao: I completely disagree with you. Interface actions should be consistent and predictable. Ctrl-click should always open a new tab in the background, and Ctrl-Shift-click should always open and switch to a new tab. Having these actions work one way when you click a link in a Web page, and work the complete opposite way when you click a link somewhere else is confusing and unnatural, and as I mentioned before, different from the way every other browser works. It can also be confusing for people who are trying to migrate to Firefox from other browsers (and aggravating for people who regularly use multiple browsers, like myself).
I did find an about:config setting called "browser.tabs.loadBookmarksInBackground". When set to true this does in fact correct the behavior so that it is no longer the opposite of clicking a Web page link (i.e., Ctrl-clicking a link in the bookmark bar will load the link in a new tab but not switch to that tab). For consistency sake this should be set to true by default.
However, "browser.tabs.loadBookmarksInBackground" it does not affect the right-click context menu. Even with "browser.tabs.loadBookmarksInBackground" set to true, if you right-click an image in a Web page then Ctrl-click on "View Image" in the pop-up context menu it will open the image in a new tab and switch to that tab (and conversely if you Ctrl-Shift-click on "View Image" it will open the image in a new tab but not switch to that tab). I cannot find a corresponding config item that applies to the context menu as "browser.tabs.loadBookmarksInBackground" applies to the bookmarks bar.
If "browser.tabs.loadBookmarksInBackground" also affected the right-click menu (or a separate config item were added for the right-click menu) it would solve this issue completely.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 7•3 years ago
|
||
The images case was resolved in bug 1706487.
Component: General → Bookmarks & History
Summary: On a link, Ctrl-click opens background tab, Ctrl+Shift+click foreground; while the opposite happens with image context menu and bookmark toolbar → On a link, Ctrl-click opens background tab, Ctrl+Shift+click foreground; while the opposite happens with the bookmarks toolbar
Comment 8•3 years ago
|
||
This is something that should be discussed with PMs, but being consistent internally and with other browsers should be fine.
Severity: normal → S3
Status: REOPENED → RESOLVED
Closed: 10 years ago → 3 years ago
Keywords: parity-chrome,
parity-edge
Priority: -- → P3
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•