Closed Bug 171132 Opened 22 years ago Closed 22 years ago

middle click on a tab should close it

Categories

(Firefox :: Settings UI, defect)

Product:
Firefox
Component:
Settings UI
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: fabricio, Assigned: bugzilla)

References

Details

I want to recommend this preference by default:

user_pref("middlemouse.contentLoadURL", false);

I think that if the middle button open new tabs it should also close.

Setting this pref by default will make the behavior of the middle click
consistent between linux and windows, and prevent troubles like bug 70498, bug
135884, bug 155851, bug 162635, and others.

Phoenix dont need to preserve 4.x behavior.
hyatt, blake, want to make a call on this?
Depends on: 170861
middle-click on linux has a much stronger association with pasting some text
than with closing something. I don't think that should be changed. Recommending
wontfix. 
Ok, some ponts:

1- The tab title, unlike text fields, is not a place to paste something.
2- Middle click don't just paste the text, the browser tries to open that text
as url.
3- Its not good for cross platform consistency.

A sugestion:

  Disable the middle click paste in the tab title area only, this area is not a
"blank area" so it's different of middleclicking on the page to open a url, and
it's not a text field also to paste text. I think that doing nothing when
middleclick on the tab title is better then try to open a page, and prevents
dataloss for people used to the windows behavior.
the number of people used to the windows behavior using linux is small. On the
other hand, the number of people using linux who know and understand the
middle-click to load a URL metaphor is not small. I don't think there's a case
for changing the existing behavior.
I don't know how great is the number of people who know and understand the
middle-click to load a URL metaphor.  And I don't know how great is the number
of people who use a dual boot machine or different OS in work/home either.

I just believe that cross platform coherence is important.

A linux person that close a tab trying to paste on a windows Phoenix is equaly
bad than the windows person who is redirect to other page when trying to close
the tab.
I agree with Fabricio, please let Phoenix close the Tab by default on middle-click.

I was just redirected to this bug because I was complaining about it and a
couple of users said it just worked, later it turned out they were using Windows.

Differences like this are just annoying and who wants to load something in the
clipboard in some tab? Yes, it is the "paste" metaphor, but is it really useful?
I'd say not. It happens quite rarely that you want to do that, but on the other
hand closing tabs happens all the time.

(Oh and BTW, it doesn't work anyway. The middle mouse button does nothing here,
which speaks volumes about the usefulness of this feature.)
That middle-click paste isn't working is bug 170861. People know and use
middle-click to paste and load a url. This is evidence by the number of bugs
reported when it breaks. (do some queries for middle click paste on linux, for
fun just query the duplicate reports). 

The real danger here is that a lot of people on linux understand middle-click to
paste something - an additive action. Closing of a page and the dataloss that
could incur is a subtractive action that can't easily be recovered from.
Reversing that metaphor on unix users is something that shouldn't be done
because a few people dual booting want consistency. It's just that kind of
"consistency" that is driving mac and linux users away from Mozilla. People
expect the app to obey the basic standards of their OS and I think middle-click
to close is in no way a standard on linux while middle-click to paste is. 
Middle click (to me) means paste text at the input focus, also moving the input
focus to the click position or at least to the clicked-in object. *However*, I'm
also used to the RISC OS approach of the left button causing one action and the
right button causing either the opposite or a similar (and related) action.

When I first found out about the middle-click closing in Mozilla (which was some
time ago now), I was somewhat surprised to find the selection being pasted into
the URL bar as well as that tab being brought to the front; I'll certainly agree
with middlemouse.contentLoadURL being false by default, and middle-clicking on a
tab to close it being available, even if not enabled by default. (Some visual
indication, such as the lack of the close icon in the tab bar, might be useful
when middle-click closing is enabled.)

At the very least, this middle-clicking business should be mentioned in the
release notes (if not already; I've just checked and didn't see any mention).

Ok, I see that this discussion could take forever, so I created an extension
that adds a checkbox to turn this preference on/off in the tab browsing preferences.

http://www.mamata.com.br/phoenix/install.html

It's my first attempt in the Phoenix extensions world, any feedback is welcome =)
I don't think that middle-click should close a tab because of consistency
(although that's a nice side-effect) I think it should do so because closing
tabs is a much, much more common action than "displaying whatever happens to be
in the clipboard".

In the rare occasions where I need that, I usually have to copy-paste an URL
from some forum - but then I still have to paste it to the location-bar to
remove the spaces most forum software is inserting!

Also, if somebody wants to REPLACE a tab with the URL in the clipboard, he no
longer wants to use that tab, so no data-loss, even if he would expect
URL-pasting because this pasting is not additive at all, it's equally
destructive to whatever was in that tab.

A nice solution to the problem would be to insert a "open clipboard in this tab"
option in the tab-menu.

I don't see tabs closing on middle click as consistent behaviour: middle click
opens, not closes. There are several outstanding bugs that aim to make opening
on middle click standard behaviour (back/forward buttons, bookmarks etc). If you
want middle click on tab to do something, have it clone the tab (IOW, open a
copy of current page in a new tab/window). It would also be nice considering
there is currently no quick way [that i know of at least] to clone a page,
whereas there are several methods for closing a tab. 
I like the arguments I'm hearing here.  That is, the ones which say "consistency
between Windows and Others be damned, the native expected response is the one
that should be provided by default".  If you don't like the way Linux works,
don't use it.  If I don't like the way Windows works, well, I don't use it.

I wish bug #64866 - "Linux: click-and-hold in scrollbar elevator should not stop
at cursor position" (I just used middle-click to paste) would get cleared up. 
Could some of you who, as I do, *like* the way Linux works jump over there and
help me out with it?  The apparent maintainer there thinks the slider should not
keep traveling past the point in the scrollbar where the left button was
clicked.  When it's pointed out that the current lame behavior is different than
every other graphical app (even using the GTK) on Linux, we're told they're all
broken.

This whole concept of "make it look and feel the same everywhere I might happen
to be using it" is what's keeping me from spending any quality time with
mozilla.  This is my maiden voyage with phoenix, and already I have to contort
to use the **** Ctrl key as a modifier...
In linux, if you middle click in the titlebar of any window it dont paste
anything, in kde it unfocus windows. 

I see the tab-title area as something similar to window-title area, I dont have
nothing against paste&go with the middle click in the *content area*, I just
think that the tab-title area should not be considered content area...
Fabricio,

I don't disagree with you that the tab area should be configurable to provide
any action whatsoever with any button.  In fact, if mozilla (in general)
wouldn't be trying so hard to completely reinvent the wheel, it could be able to
accept X resources such that any user can specify anything they want.  Want to
provide all such control in XUL or whatever?  Fine, but any X resources present
should trump everything.  I get the distinct impression there's only enough X
awareness to get the program to display and accept input - it seems somewhat
VMware-like to me.

Already the tabs provide a different action for a right-click than does the
content area, so there's some mechanism in place to provide the distinction.

As for the window title bar, that's not under the control of the application
contained within the window, and neither are the side or bottom frames of the
window.  So in that respect you might want to revise your argument.

I just saw a problem with the middle button in the content area when I went to
use it to grab your name without activating the link.  It would not work as it
should.  In fact, I see that the middle button dragged will not select *any*
text as it should.  (and would somebody please explain to me what's up with the
editing cursor in the content area when not in an input mode?  that is extremely
distracting and it makes the cursor very difficult to spot without waving it
around)  Instead, I had to start in the space to the left of your name with the
left button and then remove the initial space after I pasted.  Still better than
actually typing the name, I guess; but by very, very little.
This doesn't depend on 170861 because its fixing (or won'tfixing) doesn't
require any changes that would happen as part of 170861. 

This is the kind of issue that will only be settled by everyone being able to
configure every possible option and that's the realm of an extension like Piro's
tab browsing extension or Multizilla.
Status: NEW → RESOLVED
Closed: 22 years ago
No longer depends on: 170861
Resolution: --- → WONTFIX
taking QA contact, sorry about the bugspam
QA Contact: asa → mconnor
verified
Status: RESOLVED → VERIFIED
See also bug 171787, same bug for Seamonkey.
*** Bug 216861 has been marked as a duplicate of this bug. ***
*** Bug 221609 has been marked as a duplicate of this bug. ***
Setting middlemouse.contentLoadURL to false makes middle-clicking on tabs close
them.
*** Bug 239553 has been marked as a duplicate of this bug. ***
I agree with comment 10, but I don't use Linux often.
See also bug 199058, same bug for Seamonkey, also WONTFIX.
*** Bug 225858 has been marked as a duplicate of this bug. ***
(In reply to comment #13)
> In linux, if you middle click in the titlebar of any window it dont paste
> anything, in kde it unfocus windows. 
> 
> I see the tab-title area as something similar to window-title area, I dont 
have
> nothing against paste&go with the middle click in the *content area*, I just
> think that the tab-title area should not be considered content area...

Just to mention:
I middle-clicked on a tab, and the error message "re is not a valid protocol"
appeared.  I immediately suspected that middle-click behaviour is random on 
Firefox linux, since the other results I've achieved include page reloading, 
redirection to the home page, and visitation of previous pages in my browsing 
history.  There was no indication at all that this is a normal paste operation, 
since I do not ordinarily suppose that text can be PASTED onto a TAB, of all 
things.  It's insane that pasting text onto a tab refocuses the window and loads 
whatever is in the clipboard!  
To all intents and purposes, it is even more insane that Firefox would try to 
open something which is clearly not even a valid URL (ie, "re") and even worse, 
the errors appear to be random and non-reproducible depending on what is 
actually in the (entirely inconsistent, under Linux) clipboard.  Hell, I can't 
even copy/paste between some of my applications!!  Why should Firefox get this 
dubious behaviour by default (or, indeed, at all??!)?
The expected behaviour was to have the tab close itself.  I think anybody 
switching from Windows (which, if ESR is right, soon to be 95% of computer users 
;)) will appreciate a little normalcy.

Reproducible: Sometimes
Steps to Reproduce:
1. open a page in a new tab
2. middle-click on ANY tab
3. watch the current tab for bizarre behaviour

Expected Results:  
close the tab

As comment 13 says, it would be OK to have middle-click paste-and-go text in the 
address bar; however, having it run away from my current page and refocus the 
erroneously-pasted tab is not cool.  I'm amazed that more people haven't filed 
bug reports about this one.
ESR also thinks that good UI design can be achieved by writing the backend 
before designing the frontend. ;) However, your thesis that we should do as we 
do on Windows because of converts to Linux implies that those users are more 
important than existing Linux users who use this ridiculous feature.  They're 
not, and supporting platform/toolkit standards is a major necessity for 
integrating into an OS.  If we don't behave like native apps, we're hurting, 
not helping, ourselves.  (See discussions on GTK2 and Cancel/OK vs. OK/Cancel).

Now, the bad part is that contentLoadURL does not check whether the contents of 
the clipboard constitute a valid URI.  If we can do that, the most annoying 
part of this bug is resolved.  That's in a separate bug already, and I hope to 
get some pref UI so users can easily switch to the "Windows-style" middlemouse 
actions.
*** Bug 222640 has been marked as a duplicate of this bug. ***
Re comment 7: 

Middle-click to paste ON WIDGETS is by no means standard on Linux!
Nor or any UNIX enviroment I ever used. It should NOT be possible to paste on
tabs, scrollbars etc.

Opera has got the tabbed interface just right on Linux, and is a lot more
comfortable to use than Mozilla :( There, the tabs are closed with middle-button
click, and no paste occures. It does, however, paste if one middle clicks in the
content area.

It is very annoying, and clearly a bug, when one action performs two completely
different, even partly contradictory, tasks.

The way this bug and bug 171787 is treated reveals a negligence, lack of
insight, and all in all total arrogance towards the Linux platform.
I hadn't expected to meet that in the Mozilla environemt. It's extremely
disappointing.
Agree.

People, middle-clicking in the Toolbar doesn't load the clipboard URL. Why?

(In reply to comment #7)
> That middle-click paste isn't working is bug 170861. People know and use
> middle-click to paste and load a url. This is evidence by the number of bugs
> reported when it breaks. (do some queries for middle click paste on linux, for
> fun just query the duplicate reports). 

Actually, bug 170861 is a request for middle-click to paste URLs in Windows, and
that bug (and its duplicates) and this bug (and its duplicates) illustrate one
thing only:  the need for *consistency* between Windows and *nix, whichever way
you choose to make it.  I would suggest picking one behaviour, making it
standard on both platforms, and having an clear option in the "Options" dialogue
(about:config is not what I would call accessible to mainstream users!) to
change this - it is clearly something that many people feel strongly about and
is also clearly something that confuses many people.
except that consistency/integration with the platform is more important than
consistency with the same app on other platforms.

On windows, we should behave like a windows app.  On GTK2/Linux, we should
behave like a GNOME app.  And on OS X, we should behave like an OS X app.  So
doing something that breaks one platform or another for the sake of consistency
in the app is just a bad idea, and something we're working very hard to avoid.
*** Bug 245790 has been marked as a duplicate of this bug. ***
This "bug" has been acknowledged by several users for the past couple years now.
 Additionally, for every person who reports it, there's likely to be another
hundred lazy people who don't report it---sitting around, waiting for it to get
fixed.  (I was one of those lazy people; after 3 consecutive releases, I finally
reported it.)

There seems to be an abrasive sentiment that fixing this "bug" shows a bias
towards WINDOWS users---this is simply not the case.  Windows never had a
standard "middle-click on tab" behavior... Firebird/fox developers chose to
assign it a *close* function.

The consistency argument is applicable here. I have 5 machines with Firefox; 2
Windows boxes and 3 Linux boxes.  The application *looks* so identical that I
sometimes don't think about which OS I'm in while using Firefox.  Sometimes, I
accidentally close a tab; other times, I accidentally paste a URL.

The focus on platform-specific integration should stay on the
aesthetic/appearance side, as it has been.  However, any *behavior* should
remain the same (wherever possible), regardless of the OS.  Cross-platform
applications, especially those deployed within heterogeneous computing
environments (increasing steadily in popularity) demand this.

I'd like to see the same default behavior on both platforms.  While I prefer the
middlemouse to close tabs, I'd choose consistency even if it negates my personal
preference.

Please pick one behavior and apply it to every platform.  If it's such a big
divide, perhaps it may be worth a CHECKBOX in the preferences dialog?

...just my 2-cents. =)
note that disabling middlemouse.paste and middlemouse.contentLoadURL allows this
behaviour on Linux.  Trying to argue that look and feel are separate from
behaviour is a straw man.  If you're a linux user and used to conventions like
middlemouse.paste, you will expect that to work.  Same with the contentLoadURL
pref.  Same, for that matter, with behaviour when clicking in the URL bar.  If
it looks like a Linux app (or an OS X app) but behaves like a Windows app, it
presents a usability obstacle.

Exposing a pref on these is covered in another bug, and we should probably do
that, but the defaults will not change.

As for deploying in a hetrogenous environment, sysadmins can easily set default
prefs to match across platforms, if they so choose.
There is no non-mozilla Gnome-app that allows pasting anything on tabs or
scrollbars. That is a "feature" ONLY found in Mozilla. (this bug and bug 70698)

In general: If you can't COPY text from a somewhere, you shouldn't be able to
PASTE to it either. The tabs are "minniature titlebars". So it makes as much
sense to paste when middle clicking a tab as it would make to paste when
middle-clicking the titlebar.

Learn from Opera for Linux:
There is no need to set a pref there for middle-mouse paste/content-load-url
regarding tabs: It is simply not possible to "paste" on the Opera tabs. 
But it IS possible to load an url by middle clicking in CONTENT area.
*** Bug 268051 has been marked as a duplicate of this bug. ***
(In reply to comment #35) 
> If you're a linux user and used to conventions like 
> middlemouse.paste, you will expect that to work. 
 
I am a Linux user (and former Unix user) and in over a decade of using various 
X-programs (KDE apps, Gnome apps, old X apps) I haven't found a single program 
that allowed pasting into something that doesn't accept textual keyboard input. 
 
For things that DON'T accept keyboard input, the middle mouse button is used 
for several useful features:  
 
- Middle-click on window-decoration usually pushes it to the background, it 
doesn't paste anything.  
- Middle-click on the desktop usually opens some kind of menu, it doesn't paste 
anything. 
- Middle-click on scrollbars jumps the handle, it doesn't paste anything. 
 
 
(In reply to comment #34)
This is pretty much how I feel on the issue. I dualboot two computers and
maintain another that is Windows only - and want to have consistency between
them. It just so happens that I like the middle-mouse-to-close feature - quite
frankly I find the middle click to load clipboard URL annoying and it slows down
productivity - what if you miss a link that you want to open in a new tab? It
opens the clipboard URL which might not be a URL at all, hence sometimes
bringing you to a nonexistent site or a site full of ads and other undesireable
content. Usability is degraded. The least we could have is a checkbox in the
advanced set of preferences to turn it off. Theare are too many "unknown" prefs
and I think this is one of the more serious ones that will make the browser a
great deal easier to use for Linux users without having to add it to the config
yourself.
*** Bug 268122 has been marked as a duplicate of this bug. ***
Can there be an option under the Preferences --> Advanced --> Tabbed Browsing
which allows users to enable this feature?
(In reply to comment #41)
> Can there be an option under the Preferences --> Advanced --> Tabbed Browsing
> which allows users to enable this feature?

Agreed. There is already precedent for platform-only customization options. For
example, in Windows (FireFox .9 or so and up) , Tools --> Options --> General
--> Default Browser.

This does not exist in Firefox 1.0.1 for linux. So why shouldn't this (obviously
unix-only) option exist for linux users? People have been requesting something
like it for like 3 years now.

Even if the default is left as-is, the option would be nice. Has this already
been reassigned as enhancement? If not, then can it?
*** Bug 299958 has been marked as a duplicate of this bug. ***
*** Bug 306758 has been marked as a duplicate of this bug. ***
*** Bug 308525 has been marked as a duplicate of this bug. ***
Funnily enough, I use Firefox 1.0.6 with the Tabbed Browsing Preferences
extension, which presents you with the option of letting the middle-click close
a tab. When I first started 1.5b1, I got a screen saying it'd check for
compatible extensions (including TBP), then it installed the 1.5-compatible
version of TBP. Then how can it be that this option can't be found anywhere?
Maybe it's due to the  reorganising of the preferences dialog, but then why is
the new TBP version reported as 1.5-compatible? Maybe this is a actually a
broken extension bug, so maybe we should move this one to a more appropriate
place or create a new bug there. If anyone knows what to do, please do it and
report here when it's been done.
*** Bug 318329 has been marked as a duplicate of this bug. ***
As I was going to "complain" about this, I found comment #21 From Jesse Ruderman: "Setting middlemouse.contentLoadURL to false makes middle-clicking on tabs close
them." It kind of saved my day (if this is the correct way to say it).

Nevertheless, it should have an option in the tabs' preferences. Since the functionality is there, it should not be a big deal to have that option there. There is some room left in that window.
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → preferences
*** Bug 351933 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.