Opening bookmarks in new tabs and reusing the current tab
yuri.v.khan at gmail.com
Tue Dec 12 18:23:06 UTC 2017
On Tue, Dec 12, 2017 at 10:42 PM, Gijs Kruitbosch
<gijskruitbosch at gmail.com> wrote:
> 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.
Okay, who is the relevant owner of the Places module? I see many
commits which are authored or reviewed by Marco Bonardo who originally
marked my bug report P5 and suggested taking the approach that does
not multiply preferences.
>> 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
I do not see why consistency should be enforced in this particular
place, while it is wilfully violated in many others. The preferences
page uses checkboxes styled differently from the desktop environment
theme. The tab bar is also styled differently and does not switch tabs
on a wheel scroll. Web notifications use a custom popup and not the
system-provided notification daemon.
> 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.
It’s not only bookmarks. TMP allowed users to choose any of the three
behaviors for each of these categories: bookmarks, history, address
bar, search bar.
I used to have behavior “C” enabled for bookmarks, and, consistent
with that, behavior “C” for the address bar: Enter to open the entered
URL or search in a new tab, Alt+Enter to reuse the current tab. I do
not ever use the home button, tab syncing, or the search bar.
I kept the default behavior for clicks on links (left click navigates
in the same tab, middle click opens a new background tab), and I kept
history consistent with *that*.
For me, bookmarks and URL bar results are sufficiently different from
in-page links. For one, when I’m clicking on an in-page link, I’m
looking at the page; when opening on a bookmark or entering a URL in
the address bar, the currently loaded page is outside my locus of
attention. Opening a new tab by default preserves that page.
Confusion, well, I get that every time that I deal with Firefox that
is not configured for the workflow I have been using for the last
twelve years, or with any other browser.
> Additionally, I don't believe the suggestion that right click + left click
> is significantly more friction than a single middle click.
It is as many clicks as it takes to open the bookmark in a new tab and
then close the previous unneeded tab. I tried that, out of necessity,
and found it annoying.
> 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.
I have no statistics for the relative frequencies of opening bookmarks
in current vs. new tab. I do know I want the safe option (open new
tab) on the easier gesture (left button), and the slightly destructive
option (reuse current tab) on the slightly, but not very, more
difficult gesture (middle button). I do also know the vast majority of
my URL bar interactions open a new tab, and bookmarks should be
consistent with that.
>> Do you agree it should be an option for users?
>> If not, why not?
> 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.
That does not provide customization detailed enough.
I had experience with another very successful software product that
had first a problem with feature requests that are too costly for the
core developer to have in core and UI, and then a problem with hidden
preferences. The solution there was to expose an extension API
powerful enough for third-party developers to implement alternate
For Firefox, this strategy would probably mean to expose clicks and
[Alt+][Ctrl+][Shift+]Enter key events on in-page links, bookmarks,
home button, history items, address bar, search bar, etc.
Alternatively, a reasonable level of customizability could be achieved
by building a generic infrastructure for user-defined mapping of UI
gestures into commands. As an example, the WebExt API already lets
extensions register commands and specify key bindings. Bug 588710
exists to make those customizable. Opening a bookmark or address bar
URL in a current, new, or new background tab could all be commands in
that infrastructure, and there could be contextual gestures such as
“middle click on a bookmark” or “Alt+Enter in the URL bar”.
>> 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.
I do believe accepting the preference would give Firefox a small
(sub-)percentage of happy users.
More information about the firefox-dev