107147 - Using middle button to close a tab also pastes+opens url in another tab

Status: VERIFIED FIXED

(SeaMonkey :: Tabbed Browser, defect, P3)

Description

[Stephen Moehle]

Using the middle mouse button to close a tab seems to be conflicting with the
use of the middle mouse button to load whatever is in the clipboard as a new
URL.  The tab closes ok, but Mozilla then proceeds to load the URL which is not
what I want.  It would be better to disable the open-URL-from-clipboard aspect
of the middle mouse button when using it to close a tab.

To reproduce:
1) Copy a URL to the clipboard.
2) Use the middle mouse button to close the tab.
3) The tab closes, but Mozilla also loads the URL.

Tested with Mozilla trunk build 2001102706 on Linux.

Comment 1

[Peter Trudelle]

->097/p3

Comment 2

[Marcus Pallinger]

I also use PWM, which by default uses middle click to select tabs, resulting in
me closing tabs isntead of selecting them.

Comment 3

[Niklas Mehner]

*** Bug 110228 has been marked as a duplicate of this bug. ***

Comment 4

[R.K.Aa.]

*** Bug 111290 has been marked as a duplicate of this bug. ***

Comment 5

[Antoine Labour]

Attachment: proposed patch

Comment 6

[Antoine Labour]

I attached a proposed 1-liner patch. This one is really bugging me.

Comment 7

[sairuh (rarely reading bugmail)]

spam: set your filter for "SeverusSnape" to avoid the influx of bugmail

changing QA contact of open tabbed browser bugs from blake to me. if this bug
requires a reassignment, however, feel free to change it!

Comment 8

[August Mayer]

Proposed quick Workaround: disable the feature that loads the URL in the
clipboard on Unix systems:

add the line
  
  user_pref("middlemouse.contentLoadURL", false);

to the prefs.js file.

Comment 9

[R.K.Aa.]

*** Bug 114515 has been marked as a duplicate of this bug. ***

Comment 10

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 119012 has been marked as a duplicate of this bug. ***

Comment 11

[sairuh (rarely reading bugmail)]

marlon et al., what should we do here to resolve this?

Comment 12

[Akkana Peck]

The patch looks reasonable (though I haven't tried it).  Disabling the
middleclick-load if the click is over a tab seems fine.

Though personally, I find middle click (which means "paste something" to Unix
users, or "scroll something" to windows users and wheel mouse users) extremely
unintuitive as a Close binding; if I used tabbed browsing, I would expect middle
click on a tab to load the clipboard url into that tab, not close the tab.  Does
middleclick close anything anywhere else?

Comment 13

[Stephen Moehle]

I know no one cares what end users think, but, as a Linux user, I have exactly
the opposite expectation.  Middle-click to close a tab seems quite natural to
me.  Middle-click to load a url does not.  I have never used that feature except
by accident, and when I have, I have always been confused by the result.

Comment 14

[Brian G]

As an user, I find middle-click to open a new tab very useful.  Use it all the
time to keep my place in news sites like /. while reading a link in another tab.
 Using middle-click to close the tab makes sense, since I used middle-click to
open it.  I would prefer those behaviors stay.  I have never used the middle
click to open a clipboard URL, except to middle click *in the location bar*.

Comment 15

[jag (Peter Annema)]

I can see the logic of Brian G's comment, but one could extend that (since
middle-clicking a link generally opens that link in a new window) to mean that
middle-clicking the title bar of a window should close it (hmmm, someone file an
RFE for that ;-) ).

Stephen Moelle, can you explain why you feel it's natural that middle-clicking a
tab closes it?

Personally I feel it's "natural" that middle-clicking on a tab loads the url
currently in my selection clipboard in that tab, but that's because I'm used to
middle-click pasting selected text, and I use it quite a lot.

I compare it to drag-and-drop:
If you select text, then drag it to a textfield and drop it, it will put that
text in the textfield. If you drag it to a browser window and drop it, it will
try to load that text as if it were a url (which works quite well if the text
indeed is a url). On linux, in addition to standard drag-and-drop, there is the
option of drag-selecting the text, then "dropping" it somewhere by
middle-clicking the mouse. This "dropping" should have the same result as a drop
from a drag-and-drop action.

If you don't agree with me then luckily you can turn these features off by
adding these lines to prefs.js:

user_pref("middlemouse.paste", false);
user_pref("middlemouse.contentLoadURL", false);

Since drag-and-dropping a url to a tab loads that url in that tab, I suggest
that we look at the middlemouse.contentLoadURL preference, and if it's set to
false, middle-click closes the tab, if it's set to true, the text in the
selection clipboard is loaded as a url.

Comment 16

[jag (Peter Annema)]

Comment on attachment 58941 [details] [diff] [review]
proposed patch

For future reference, it should be ".localName", not ".local_name", and there's
no need to toLowerCase() it since it can only be lower case "tab" (xml, unlike
html, is case sensitive).

Comment 17

[Stephen Moehle]

Responding to jag in Comment #15:
I find middle-clicking to close a tab natural since there certain symetry with
using a middle-click to open the tab in the first place.

I do not have a problem with your suggestion of disabling middle-click to close
if middlemouse.contentLoadURL is true.  I have had that preference set to false
for quite a while now.

I do think Mozilla/Netscape should do usability testing to see if it is really a
good idea to have contentLoadURL default to true.  I have been using Linux more
than 3 years and Mozilla for nearly 2, and I found the
middle-click-to-load-a-URL behavior to be very confusing until I figured out
what was going on.  Unless you know about middle-click, then every time you do
so either deliberately or by accident, you load a new web page, get a 404 error,
or some other weird error because the contents of your clipboard can be pretty
random.  This is especially true if you are only expecting (as I did before the
advent of tabs) that middle-click can be used for pasting.

I think this middle-click-and-load-a-URL feature may be confusing for your
standard Gnome or KDE user.

Comment 18

[Hampton Maxwell]

I see the tab as having different purpose from the url bar.  The url bar is a
navigational tool, tabs are a window management tool.       Therefore, if a user
wants to load a url by middle-clicking, he should do it by middle clicking the
url bar not the tab.  Anything else seems non-intuitive to me.  There is already
an RFE to open new tabs by middle-clicking the tab bar, so this behavior would
fit that.

This is also confusing as it creates different behavior between Windows and Linux.  

The current behavior is broken anyway since using middle click to load the url
in a tab causes it to issue both a load and close request and the tab gets closed.

Comment 19

[David Hyatt]

Reassigning to new component owner.

Comment 20

[Max Waterman]

I would like to point out another unexpected interaction.

I use netscape and mozilla on Linux and IRIX and have done so for a long time.
I extensively use 'middle-click' to make a browser go to that URL, by
middle-clicking on the background of the page currently displayed. It seems
natural to me. I haven't used tabs extensively yet, but my vote would be to have
the tab jump to the clipboard contents as if it were a URL (perhaps the s/w
could validate the contents to see if it is a valid URL and not jump if it isn't?).

The behaviour change (bug?) I have noticed is middle-clicking on the right hand
scroll bar - on a compose message window. It jumps (not scroll - that's the left
 mouse button) to the point on the bar that I've clicked, but also unexpectedly
pastes the clipboard contents into the message. This didn't use to happen and is
a bug.

Max.

Comment 21

[Akkana Peck]

Max: please file that as a separate bug, and please cc me (or assign it to me if
it also happens in the editor window).  It shouldn't paste when you middle-click
in the scrollbar; it's probably something like PreventBubble not being called.

Comment 22

[Stefan Borggraefe]

Why wasn't patch 58941 applyed? The middle mouse button clearly has TWO
functions when used on tabs, which is a bug. The patch is the trivial fix for
the problem. The two alternatives to the patch outlined here are:

1. disabling the page load on paste completely
2. disabling the closing of tabs with the middle mouse button

Both alternatives would lower the useability of the browser by disabling useful
features. The patch solves the problem without disabling any features and is in
my opinion the best solution for this annoying problem.

Comment 23

[R.K.Aa.]

*** Bug 121756 has been marked as a duplicate of this bug. ***

Comment 24

[jag (Peter Annema)]

Stefan:

The patch doesn't work as intended (see comment 16).

Also, I would like to suggest 2b: when contentLoadURL is set to true,
middle-click loads the url, otherwise it closes the tab.

Comment 25

[R.K.Aa.]

*** Bug 124702 has been marked as a duplicate of this bug. ***

Comment 26

[Peter Trudelle]

nsbeta1- per ADT triage team.  This is a problem, but we'll live with it for
MachV. ->1.2

Comment 27

[R.K.Aa.]

*** Bug 130249 has been marked as a duplicate of this bug. ***

Comment 28

[Jeremy M. Dolan]

How about disabling close completely for now, since it's terribly buggy. Then
worry about reintroducing it correctly later, if it's really desired. (A small X
on each tab, a seperate RFE, is the proper way to do what you're trying with
middle click, IMO).

Also, middle-click to paste a URL on a blank part of the tab bar seems not to
open a new tab anymore, but load in the current... highly unintuitive and very
useless (I can just middleclick the page).

Comment 29

[Stephen Moehle]

I use middle-click to close tabs all the time, and I never use middle-click to
paste or load anything so once I heard about the middlemouse.contentLoadURL
preference, my problems were solved.  There is no guarantee that any RFE's about
X's on tabs will ever be implemented so please do not get rid of
middle-click-to-close on the assumption that something else may or may not
provide the same functionality in the future.

Comment 30

[Boris Zbarsky [:bzbarsky]]

*** Bug 135283 has been marked as a duplicate of this bug. ***

Comment 31

[August Mayer]

The life of this bug seems exemplaric to me for the mozilla syndrome: small bug,
quick patch, but then: error in patch, nobody cares, "we'll live with it". And
with the missing Xes on the tabs, I'd have to aim for the small tab close
button, then search again which tab is now current - usability problem.
Oh well, I'm using galeon now, which doesn't have such brain-dead ui bugs.

Comment 32

[Hixie (not reading bugmail)]

Shouldn't the fix be to stop the event propagating once we've handled the click
that closes the tab? I'm sure if someone comes up with that fix (which would
probably also be a one liner) then I can push to get it reviewed and checked in.

Comment 33

[R.K.Aa.]

*** Bug 147417 has been marked as a duplicate of this bug. ***

Comment 34

[R.K.Aa.]

*** Bug 149232 has been marked as a duplicate of this bug. ***

Comment 35

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Fix v.1.0

Does what jag wants: checks the pref.  I am also in favor of doing it this way.
 As a linux user, it makes much more sense to me.

Comment 36

[Christopher Aillon (sabbatical, not receiving bugmail)]

taking

Comment 37

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Fix v.1.1

Better patch.

Comment 38

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Patch v.1.2

Jag and I talked about it, and agreed on the patch done this way.  Ah the
wonders of code.  So many ways to write things....

Comment 39

[jag (Peter Annema)]

Comment on attachment 92091 [details] [diff] [review]
Patch v.1.2

sr=jag

Comment 40

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 92091 [details] [diff] [review]
Patch v.1.2

r=sicking

Comment 41

[Brendan Eich [:brendan]]

Comment on attachment 92091 [details] [diff] [review]
Patch v.1.2

a=[e-mail] for trunk checkin ASAP.

/be

Comment 42

[Christopher Aillon (sabbatical, not receiving bugmail)]

Landed on the trunk.

Comment 43

[Kai Lahmann (is there, where MNG is)]

hm.. is there any GUI for 'middlemouse.contentLoadURL' ?

Comment 44

[Akkana Peck]

There is a bug languishing somewhere with a patch for adding UI for
middlemouse.contentLoadURL, but I can't find it.

Comment 45

[Jesse Ruderman]

Akk: I see bug 135884, "Middleclick on browser content area loads clipboard as
URL", but that doesn't have a patch and it's not clear whether it's about
changing the default behavior, adding a pref, or both.

Comment 46

[Akkana Peck]

Maybe I'm hallucinating, though I could swear I saw a patch to that effect
somewhere.  Can't find the bug, though.

Comment 47

[Christopher Aillon (sabbatical, not receiving bugmail)]

Jag mentioned it to me the other day.  There is a patch that IIRC he owns, and
is just awaiting checkin.  But I don't know where it is either.

Comment 48

[Stefan Borggraefe]

*** Bug 152774 has been marked as a duplicate of this bug. ***

Comment 49

[Roland Seuhs]

Why middle-click should close tabs: 
<p> 
When you use tabs, you sooner or later run into the problem of getting rid of them again. There are 4 possibilities to do 
that: 
<p> 
1: Middle-click on tabs <br> 
2: Left-click tabs and close each with the "x" on the right <br> 
3: Rigth-click tabs and choose "close tab" from the menu <br> 
4: Implement an "x" on each tab 
<p> 
2 and 3 are obviously annoying and 4 is a bit better but introduces a smaller target area (the "x" instead of the whole tab) 
and the "x" takes away useful space that would otherwise be used to describe the contents of the tab. 
<p> 
IMO, the current behaviour (well, at least when it works) is the best. 
 
 

Comment 50

[Roland Seuhs]

I think the only problem of middle-clicking tabs to close them is that it's non-obvious.  
 
That could be easily solved by just adding "(middle-click)" beside "close tab" in the context menu on right-click. 
 

Comment 51

[Boris Zbarsky [:bzbarsky]]

*** Bug 166823 has been marked as a duplicate of this bug. ***

Comment 52

[sairuh (rarely reading bugmail)]

okay, when i middle-mouse click, the tab never closes. what happens is that it
loads the url (which i recently copied) in the frontmost tab. this occurs
whether i middle-mouse click on a background or the frontmost tab

tested on linux rh7.2, 2002.09.19.08 comm trunk.

Comment 53

[R.K.Aa.]

*** Bug 183125 has been marked as a duplicate of this bug. ***

Comment 54

[Mauricio Silveira]

Let's just think a little about this "bug", considering the comments:

1.) Middle-click on current page's body may be annoying when you wanted to
middle-click the LINK to open a new tab/window and what you get is the url on
the clipboard to be loaded on that tab.
2.) If middle-click is meant to paste stuff on *nix, why should it be natural to
perform a close on the tab?
3.) The `X' on each tab should help.
4.) Closing the current tab and pasting the clipboard contents on the most-left
tab IS MEANT to be a BUG.

So, my thoughts about tab navigation and middle-click behavior is that things
should be like this:
1.) A single middle-click over a tab should paste the url in case
middlemouse.contentLoadURL == true ; Shouldn't a double middle-click be added
for closing the tab in this case? And case middlemouse.contentLoadURL == false,
shouldn't both single middle-click and double middle-click close the tab?
2.) Middle-click over the tab bar with an url in the clipboard should open the
url in A NEW TAB.
3.) Shouldn't specific "current page middle click for new URL", the middle-click
over the page's body have a user_pref statement for the sake of
enabling/disabling it?(I would disable it, i usually missclick urls i want in a
new tab :).

This is what i may name a "perfect behavior" for middle-click.

BTW... I have duplicated this bug as bugzilla did not return my query for middle
AND tab AND close, think the search system is messed(look, i know this is
off-topic for this bug!).

Wish i have a quick response for my proposals.

-MS

Comment 55

[Christopher Aillon (sabbatical, not receiving bugmail)]

Here's your quick response: this specific bug is fixed, and has been for a while
now.  If you want to make a proposal, do so in a new bug.  Thanks.

Comment 56

[Jeremy M. Dolan]

I see the same thing as sairuh reported in comment 52. Is there a new bug for
that, or was this never fixed?

Comment 57

[Akkana Peck]

I don't know of a bug for that or for Mauricio's suggestions (which sound
reasonable to me).  Perhaps you or Mauricio will file one.  Please cc me if you
do (or just assign it to me) -- I might be able to offer a patch.

Comment 58

[Stephen Moehle]

Please, I beg you, do not take away the ability to use a single middle-click to
close a tab.  Double-clicking is evil. (And it aggravates my wrist problems.)

Comment 59

[R.K.Aa.]

Now bug 199058 is filed. This bug is simply NOT fixed. It should not be possible
to paste anything on a tab! As little as it should be possible to paste things
on a scrollbar, a button etc etc.

There used to be  bugs about that too, but they are fixed. Can't a similar fix
be applied to the tabs?

Several people have voted for this bug. Even more have had their bug-reports
resolved as duplicates of this bug. And then the fix.... turns out to not fix
the original bug at all. I quite agree with comment 31. There's a pattern here.