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.