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.

->097/p3

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

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

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

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!

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.

*** 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?

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?

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.

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

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.

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.

Reassigning to new component owner.

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.

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.

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.

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

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.

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

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

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

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

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

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.

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

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

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.

taking

Better patch.

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 on attachment 92091 [details] [diff] [review] Patch v.1.2 sr=jag

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

Comment on attachment 92091 [details] [diff] [review] Patch v.1.2 a=brendan@mozilla.org for trunk checkin ASAP. /be

Landed on the trunk.

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

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

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.

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.

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

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.

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.

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

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

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.

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

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.

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

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.