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

VERIFIED FIXED in mozilla1.2alpha


17 years ago
5 years ago


(Reporter: smoehle, Assigned: caillon)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment, 3 obsolete attachments)



17 years ago
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.
Ever confirmed: true

Comment 1

17 years ago
Priority: -- → P3
Target Milestone: --- → mozilla0.9.7

Comment 2

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

Comment 3

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

Comment 4

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


17 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Comment 5

17 years ago
Created attachment 58941 [details] [diff] [review]
proposed patch

Comment 6

17 years ago
I attached a proposed 1-liner patch. This one is really bugging me.
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!
QA Contact: blakeross → sairuh

Comment 8

17 years ago
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

17 years ago
*** Bug 114515 has been marked as a duplicate of this bug. ***
*** Bug 119012 has been marked as a duplicate of this bug. ***
marlon et al., what should we do here to resolve this?
Keywords: nsbeta1

Comment 12

17 years ago
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

17 years ago
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

17 years ago
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*.
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 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

17 years ago
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

17 years ago
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.


17 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Comment 19

17 years ago
Reassigning to new component owner.
Assignee: hyatt → jaggernaut

Comment 20

17 years ago
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.


Comment 21

17 years ago
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

17 years ago
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

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

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

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

Comment 26

17 years ago
nsbeta1- per ADT triage team.  This is a problem, but we'll live with it for
MachV. ->1.2
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla0.9.9 → mozilla1.2

Comment 27

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

Comment 28

17 years ago
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

17 years ago
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.
*** Bug 135283 has been marked as a duplicate of this bug. ***

Comment 31

17 years ago
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.
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

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


17 years ago
Blocks: 144260

Comment 34

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


17 years ago
Summary: Using middle button to close a tab conflicts with using it to open URL → Using middle button to close a tab also pastes+opens url in another tab
Created attachment 92060 [details] [diff] [review]
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.
Attachment #58941 - Attachment is obsolete: true
Assignee: jaggernaut → caillon
Created attachment 92091 [details] [diff] [review]
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....
Attachment #92084 - Attachment is obsolete: true


17 years ago
Attachment #92091 - Flags: superreview+
Comment on attachment 92091 [details] [diff] [review]
Patch v.1.2

Comment on attachment 92091 [details] [diff] [review]
Patch v.1.2 for trunk checkin ASAP.

Attachment #92091 - Flags: approval+
Landed on the trunk.
Last Resolved: 17 years ago
Resolution: --- → FIXED
hm.. is there any GUI for 'middlemouse.contentLoadURL' ?

Comment 44

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

Comment 45

17 years ago
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

17 years ago
Maybe I'm hallucinating, though I could swear I saw a patch to that effect
somewhere.  Can't find the bug, though.
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

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

Comment 49

17 years ago
Why middle-click should close tabs: 
When you use tabs, you sooner or later run into the problem of getting rid of them again. There are 4 possibilities to do 
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 
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. 
IMO, the current behaviour (well, at least when it works) is the best. 

Comment 50

17 years ago
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. 
*** Bug 166823 has been marked as a duplicate of this bug. ***
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

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

Comment 54

16 years ago
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.

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

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
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.
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.