216861 - Middle-mouse clicks on the tab-bar in Linux should close tab (as is the case in Windows)

Status: VERIFIED DUPLICATE of bug 171132

(Firefox :: General, enhancement)

Description

[Owen Marshall]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030820 Mozilla Firebird/0.6.1+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030820 Mozilla Firebird/0.6.1+

There is currently an inconsistent approach to treating middle-mouse-button
clicks on open tabs in Mozilla.  Under Windows, middle-clicking on an open tab
will close that tab; under Linux, middle-clicking on an open tab opens the
content of the X-selection as a web site (e.g. "mozilla" is selected,
middle-clicking results in that tab opening www.mozilla.org)

As someone who regularly has at least 20 tabs and up to 50-60 tabs open at any
one time, the ability to close tabs quickly (and without loading the contents of
that tab back into memory if it has been swapped out) is vital, and I find that
middle-clicking solves this problem very well - it is fast, quick and efficient.
 I would therefore suggest that this feature be added to the browser under linux
as well.  (Pasting the X-selection as an address under linux can already be
accomplished by middle-clicking in the browser window, so this functionality
would not be lost if middle-clicks on tabs were assigned to closing the tab)

At least, would it be possible to have a selectable option (even just one
accessible in about:config) that would provide this functionality?

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Jesse Ruderman]

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

Comment 2

[Mike Connor [:mconnor]]

v

Comment 3

[David P James]

I use ContentLoadURL all the time -- in the rendering area. I don't see why 
that has to be extended to the tab bar however. In my view the two functions, 
which for no good reason at all currently conflict could in fact live together 
quite happily. I agree with the reporter on this one, who, unlike the reporter 
of bug 171132 does not want to see ContentLoadURL done away with.