Opening bookmarks in new tabs and reusing the current tab

Robert Bücheler rf.buecheler at
Tue Dec 12 16:37:20 UTC 2017

On Tue, Dec 12, 2017 at 9:42 AM, Gijs Kruitbosch wrote:

> On 07/12/2017 03:25, Yuri Khan wrote:
>> This leaves out one other case “C” that was possible with TMP. It
>> effectively swaps the left and middle click functions with respect to
>> bookmarks:
>> * If the current tab is pinned, the bookmark is opened in a new tab.
>> * Left click opens the bookmark in a new tab.
>> * Middle click opens the bookmark in the current tab (unless it is
>> pinned).
>> * Right click works the same as default.
>> [snip]
> So now we are left with the following situation:
>> 1. There is a group of end users who want behavior “C”.
>> 2. Two core developers object against replacing the existing behavior
>> “B” with behavior “C”.
>> 3. Two core developers agree that behavior “C” is sensible.
> I don't think that confirming a bug necessarily means that people agree
> with you, just that the bug as filed is a valid enhancement request - which
> relevant peers/owners of a module might still end up disagreeing with.
>> 4. One core developer objects against having two separate preferences
>> for the left and middle buttons.
>> I am now asking for opinions. Do you agree behavior “C” is sensible?
> No.
>> If not, why not?
> It breaks consistency in the UI: middle click always opens in a new tab.
> This doesn't just apply to bookmarks, and it's considered a bug if/when we
> break that functionality, including longstanding bugs about e.g. making
> javascript: links work when opened in a new tab. It's not clear why you
> think bookmarks specifically need to have this strange middle click
> behaviour, and why it wouldn't govern anything else (like other in-UI
> things that open pages, like the home button, history items, synced tabs,
> etc. etc.). It'll likely lead to more confusion.

Sorry, here I disagree. With Logitech, I have the opion to set my middle
mouse button to whatever I want (well, whatever they have in their function
list, and that is pretty large.)
browser.tabs.loadBookmarksInTabs was introduced with Bug 658245
<> to enable laptop
users (and users with 2-button mice[sic]) to enable one-click method to
open bookmarks in new tabs.
I am supposing that the originator of the above bug had (or has) a laptop
that doesn't allow left+right-mouse(touchpad-button)-click or the
three-finger-tap on the touchpad.
I do believe that while there is validity in the "bug 658245" to set the
left-mouse-button to open bookmarks (or links) in a new tab, the opposite
should be valid too, to open a bookmark (or link) in the active tab
(provided it is not a pinned tab) with the middle-mouse button. (sort of
what TMP used to do pre-WebExtensions)
Now since Bug 658245 has been implemented, why not implement it correctly
to actually switch the middle-mouse button action with the left-mouse
button action. Therefore still allowing for open-in-new-tab and

> Additionally, I don't believe the suggestion that right click + left click
> is significantly more friction than a single middle click.

If that's the case, why was the bug implemented in the first place?

Alternatively, if this is the majority of your use of bookmarks, you should
> probably just revert the original pref you're concerned with so that the
> default is opening in the current page and you can use middle (or
> modifier-) click to open bookmarks in a new tab. In other words, even if I
> thought that consistency wasn't important enough, I think the improvement
> the suggested change would bring to your usecase is so minor it's not worth
> the added complexity.

I am not sure how more complex the switch would be.

>   Do you agree it should be an option for users?
> No.

yes. (but not exactly as an option, but as a switch since the option is
already there)

>> not, why not?
> Because we already have a dozen or so prefs on this type of thing,
> governing what happens with in-content links, bookmarks, the context menu
> search engine item, etc. etc. Whether they load in windows or tabs, whether
> those tabs get put in the foreground, whether they are placed next to the
> existing tab or not - the list goes on, and the current situation is messy
> and inconsistent and already gathers lots of complaints, but "mostly does
> the right thing for most people most of the time".
> I would support patches that would simplify this situation without
> regressing the common case (or common customizations). I don't see a good
> reason to make the situation worse by adding Yet Another Preference.

not another preference, just switch the button action with the already
existing browser.tabs.loadBookmarksInTabs

> More generally, hidden about:config preferences for UI behaviour are an
> anti-pattern. Firefox should work for most people out of the box, and
> detailed customization should be easily and intuitively accessible to users
> either through add-ons or builtin, designed-to-be-user-facing pages like
> the settings/options page, the add-on manager or the toolbar customization
> UI -- not through byzantine key/value editing interfaces.

Firefox does work for most people right out of the box, but with the
implementation of the aforementioned bug, something breaks, and that is the
option to open bookmarks/links in the same tab.

While I /*could*/ agree with you and :Dolske that middle-click should
always open in a new tab, having two buttons that do the same makes less
sense than switching middle- and left-click to still provide the same
options if a different mouse is plugged in, which is customary in laptops.
Since the "enhancement" was designed for a "1-click" feature, the opposite
1-click feature was thus removed. Yes, the context menu is available to
open the bookmark (in the current tab), but the same is true
pre-enhancement to open the bookmark in a new tab.
I am in agreement with the bug reporters that the left-click / middle-click
should be switched if the pref is set, requesting the WONTFIX to be removed
in bug 1397372.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the firefox-dev mailing list