Opening bookmarks in new tabs and reusing the current tab
gijskruitbosch at gmail.com
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
> * 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.
> 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.
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?
> 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
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.
More information about the firefox-dev