199058 - clicking middle mouse button does not close tab

Status: RESOLVED DUPLICATE of bug 171787

(SeaMonkey :: Tabbed Browser, defect)

Description

[Jeremy Lin]

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.

Comment 1

[R.K.Aa.]

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

Comment 2

[R.K.Aa.]

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

Comment 3

[R.K.Aa.]

->Tabbed Browser

Comment 4

[R.K.Aa.]

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.

Comment 5

[jag (Peter Annema)]

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.

Comment 6

[R.K.Aa.]

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

Comment 7

[Malcolm Smith]

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.

Comment 8

[Jo Hermans]

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

Comment 9

[Jesse Ruderman]

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

Comment 10

[Jesse Ruderman]

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

Comment 11

[R.K.Aa.]

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