Opening bookmarks in new tabs and reusing the current tab

Robert Bücheler rf.buecheler at gmail.com
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
<https://bugzilla.mozilla.org/show_bug.cgi?id=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
open-in-same-tab.


> 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)

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

Robi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20171212/c5b69e58/attachment-0001.html>


More information about the firefox-dev mailing list