User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 I don't know if this is supposed to be a documented feature, but middle-clicking on a tab in Windows makes the tab close. On Solaris, it seems to make the location go to whatever is the current X selection. That is, if you have "click" currently selected, it'll try to go to "click", by which you end up at "www.click.com". Reproducible: Always Steps to Reproduce: 1. Select some text (e.g. "foo"). 2. Middle click on a tab. Actual Results: Mozilla tries to change the *current* tab's location to "foo" (regardless of which tab you actually clicked on). Expected Results: It should have closed the tab you clicked on.

The problem is that browser tabs acts like they are browser content area. But you can avoid this annoyance by adding a line to prefs.js (while mozilla is not running) user_pref("middlemouse.contentLoadURL", false); The setting will still allow tabs or windows to open when middle-clicking links

this is a duplicate btw, of bug 107147, which for some reason is resolved as fixed. It was never fixed.

->Tabbed Browser

Bug 53537 was a similar case: Middle button mouse-click on scrollbar would paste to urlbar. See bug 53537 comment 3. A tab in the tabbed browser interface is just a button. It should NOT be possible to paste on it.

I disagree. Just as you can drag a link to a tab label and have the link load in the tab, I think it's quite reasonable for middle-mouse paste to work through tab labels when that pref is set. WFM/WONTFIX.

That is very wrong of you. The functionality of a middle click on *NIX should NOT be allowed to interfere with the basic functionality of a middle click on the tabbed browser's main widget. One should only be able to paste onto something one can also copy from. Your comparision with Drag&Drop is also wrong: During a D&D you get a visual feedback about what is about to happen. While middle clicking a tab on *NIX is now by default provide an UNexpected result. One shouldn't have to add lines manually to preferences in order to get basic defaults to work. Defaults should be good right from the start. Instead - in this case - the middle click interferes with THE basic functionality a middle click on that particular widget should have. If you maintain this decision, the implementation of the tabbed interface on interface on Linux is only cemented as immature and badly designed. This is NOT "doing the right thing".

I agree strongly with comment #6. In the default configuration on Unix there is no way to close a tab by mouse without first activating it and then sending the pointer way over to the side of the screen to press the X. I don't want to use right-click -> close tab because (a) it's much more fiddly and (b) the potentially catastrophic effects of picking Close Other Tabs by accident. Having middle-clicking on a tab try and load the contents of the clipboard as a URL is a definite violation of the rule of least surprise, especially when you have it on good authority that it's meant to close the tab! The solution is simple: either stop trying to paste things into the tab (it's a TAB, not a text box), or make middlemouse.contentLoadURL false by default.

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

See also bug 171132, same bug for Firefox, also WONTFIX.

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

*** This bug has been marked as a duplicate of 171787 ***