Opening bookmarks in new tabs and reusing the current tab

Gijs Kruitbosch gijskruitbosch at
Tue Dec 12 15:42:39 UTC 2017

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

Additionally, I don't believe the suggestion that right click + left 
click is significantly more friction than a single middle click. 
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.
>   Do you agree it should be an option for users?
>   If
> 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 

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.

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.

To be extra clear, that doesn't mean making UI checkboxes for all these 
prefs (which would violate "easily/intuitively accessible" as well as 
meaning we don't make enough decisions on behalf of users out of the 
box) - it means we should get rid of some of the prefs.
>   Do you think a single boolean preference is not enough
> but two boolean preferences are too many so we should change to a
> single tri-state preference? Do you think it should not be preferences
> but rather extension API?
I would rather get rid of the existing preference, if anything, but I 
accept that there are probably a sufficiently large number of people who 
want to always open things in a new tab and/or don't have a middle mouse 
button. The group of people who want the behaviour you want is of 
necessity going to be a subset of that group of users, ie smaller.

I don't think there's a reasonable way to make an add-on API without 
having a preference, and I doubt that the add-ons team would want an API 
for just this thing -- but that's up to them.
> I am prepared to spend time to implement the feature in any way that
> is deemed acceptable and that gets me my preferred behavior in
> Firefox.
Wontfix specifically means "we wouldn't do this even if there was a 
patch". P5, what your dupe got set to originally, is closer to what you 
suggest, ie "we aren't going to do this unless someone else shows up and 
does all the work". But as it is, I'm pretty convinced we shouldn't do this.

~ Gijs

More information about the firefox-dev mailing list