Closed Bug 1439247 Opened 7 years ago Closed 1 year ago

"close tab with middle click" feature is disruptive on touchpads where middle click is triggered unintentionally

Categories

(Core :: Widget: Gtk, defect, P3)

defect

Tracking

()

RESOLVED FIXED
125 Branch
Tracking Status
firefox125 --- fixed

People

(Reporter: td_safemail-tmp, Assigned: stransky)

References

Details

Attachments

(1 file, 3 obsolete files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID: 20180209193630 Steps to reproduce: I have sensitive touchpad on my laptop and often double-click is captured when the mouse is over a tab and close the tab. Actual results: Tab is closed unwillingly Expected results: I suggest an option like /Middlemouse.contentLoadURL/ should be introduced to be able to prevent this behaviour. This option could be /Middlemouse.closeTab/ (false|true) or /browser.tabs.middleclick.closeTab/ (false|true) People with hand disabilities experienced the same difficulty. This feature has been requested by others users like here https://superuser.com/questions/113048/how-do-i-prevent-firefox-from-closing-tabs-on-middle-click
Severity: normal → enhancement
Component: Untriaged → Tabbed Browser
OS: Unspecified → All
Hardware: Unspecified → All
I second this motion. I've only discovered this behaviour in the last couple of days, as I find myself middle-clicking tabs with the intention to clone (sic!) them - presumably because middle-clicking a link on a page opens a new tab (which I do make use of a lot). I find it rather frustrating that middle-clicking a tab does pretty much the exact opposite of what I seem to be intuitively expecting, even more so since the actual behaviour is a destructive and non-trivial-to-undo operation. I see no necessity for middle-clicks to close a tab, as each tab already provides a means to close it via a left-click on the "X". So yes, please give us an option to turn this off. The sooner the better.
I find this highly annoying now as well (new laptop with large and sensitive touchpad).
Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 616130

(In reply to Christoph Lipka from comment #1)

I see no necessity for middle-clicks to close a tab, as each tab already
provides a means to close it via a left-click on the "X".

So yes, please give us an option to turn this off. The sooner the better.

I agree that it should be an option if for no other reason than accessibility, but, to address "I see no necessity":

Middle-click to close tabs is for people like me who want to be able to close tabs other than the active one without having to bloat out their tab bar by showing the close button on non-active tabs.

(eg. I've got a tab unloader extension and, sometimes I realize I won't be getting to something after all, so I use the tooltips to identify and the middle-click to close a batch of tabs without having to first trigger them to be reloaded by left-clicking on them.)

(In reply to j.b.shirk from comment #7)

I hate this! It keeps happening and it pisses me off because undoing is a minimum 5 clicks deep, thanks to ff's buried history access.

You can do it in two by right-clicking one of the remaining tabs and choosing "Undo Close Tab" or you can just hit Ctrl+Shift+T.

This issue is extremely frustrating, particularly given how poor trackpad support on Linux tends to be. I am constantly closing tabs accidentally by having my finger a little too far to the right during a click.

I am willing to write a patch for this if the component owner will agree to certain behavior (e.g. just a hidden pref to turn off middle click close? Disable middle click close by default with a pref to enable?).

I'm working on an old HP Z-book with a stupid 3 mouse button layout on the trackpad, and I've accidentally closed tabs multiple times when I thought I was clicking to activate the tab. Hard to believe this is 3 years old and still not an option. Closing tabs with a middle click also doesn't seem that useful, I can just right click and close them. Please add this as an option.

(In reply to Wolfgang Meyers from comment #13)

Closing tabs with a middle click also doesn't seem that useful, I can just right click and close them.

Please don't antagonize those of us with the opposite opinion. (I make heavy use of middle-click tab closing and never hit it by accident on any of my devices.)

(In reply to Stephan Sokolow from comment #14)

(In reply to Wolfgang Meyers from comment #13)

Closing tabs with a middle click also doesn't seem that useful, I can just right click and close them.

Please don't antagonize those of us with the opposite opinion. (I make heavy use of middle-click tab closing and never hit it by accident on any of my devices.)

I'm not antagonizing anyone. From my point of view, it's not that useful. From yours, it is quite useful. There isn't anything wrong with either perspective, but it points out that there should be a configuration to make the browser behave one way or another here. Part of the problem is the bad design of the trackpad I'm using - with just about any other device it wouldn't be an issue.

(In reply to Wolfgang Meyers from comment #15)

I'm not antagonizing anyone. From my point of view, it's not that useful. From yours, it is quite useful. There isn't anything wrong with either perspective, but it points out that there should be a configuration to make the browser behave one way or another here. Part of the problem is the bad design of the trackpad I'm using - with just about any other device it wouldn't be an issue.

Fair. My phrasing wasn't the best either. I should have said something like "Please try not to come across as dismissive of how much others value the feature."

(Were I in your situation and not on the wrong end of a bad night's sleep, I'd have phrased that something like "Closing tabs with a middle click isn't really useful to me.")

Specifically created a Bugzilla account to comment on this.
The feature may be part of people's normal workflow, however for users with a sensitive touchpad this could be a very frustrating accidental occurrence. Users have posted CSS workarounds (see https://support.mozilla.org/en-US/questions/1254024), but it would be ideal to have a supported menu option to disable this middle click.

I've been using Firefox since it was Phoenix and I never really paid attention to how middle click closes tabs until last week when I got a new laptop which maps middle click into a click on the middle of the trackpad. There's nothing visible on the trackpad to indicate where left click ends and middle click begins and I find myself suddenly mistakenly middle clicking all the time and I have to customize software to compensate.

Input systems are diverse. For decades I did not have this problem and now suddenly I do. It's really important that these types of behaviors be customizable.

I have an issue on the HP trackpad, which has no physical indicator where any of the buttons start or stop. It isn't like I am using a 3-4 button mouse. The kids can't use it because they keep accidentally closing tabs. I would love to disable it.

More then one time. I have reached around one of the kids to show them an open tab, and accidentally closed it.
I know you can ctrl-shift-T to reopen it, but I am guessing most users don't even know about it since I'm not seeing an 'undo' option.

It seems poorly thought out. There is already an x to close it in the tab. I am not sure why it needs to be replicated with a middle click.

(In reply to Sean from comment #19)

It seems poorly thought out. There is already an x to close it in the tab. I am not sure why it needs to be replicated with a middle click.

I agree there should be an option to disable it, but only an option. Being able to middle-click is very useful if you want to close a tab without having to focus it, given the time it takes to get the pointer over the tab, right-click, and then get the pointer over the correct menu item.

I use it in conjunction with the Auto Tab Discard extension as a way to close discarded tabs without having to re-load them first.

Any update on this? It is too easy to close tabs by accident using the mmb

Many laptops have not separate buttons, and as others have commented, where I place the finger to click on the trackpad sometimes causes me to close the tab instead of activate it. Luckily I am aware of this behavior and can quickly undo it and replace my finger, but it would be very helpful to disable that behavior all together. Any update?

I don't know if it's because the actual middle click area is defined differently/larger under Linux on my Surface Laptop 3 than under Windows, but I'm accidentally closing tabs instead of focusing them several times per day when using Linux (same experience under Ubuntu and Fedora). Never had issues with it on my other touchpad devices but it's a weird feeling to see your tabs just disappear while working.

Would absolutely love for it to be a toggle instead of trying to learn how to re-map the button areas of my touchpad.

Assignee: nobody → github-12-2017-ds8
Status: NEW → ASSIGNED
Attachment #9256097 - Attachment is obsolete: true

Per discussion on the phab patch:

! In D146854#4807708, @Gijs wrote:
Thank you for taking the time to submit a patch.

I'm concerned that we're basically compensating for hardware/driver issues by adding a pref in Firefox. The pref is also hidden and so many/most people won't find it, and continue to be frustrated - but on the flip side, most people won't need it and as a result exposing it in about:preferences also doesn't seem like a good idea.

So honestly, this doesn't seem like the right trade-off to me. The same issues that people are annoyed about here would apply in other pieces of software, and indeed in other places in Firefox (e.g. middle-clicking bookmarks, links in-content, etc.)

ISTM the right fix is to disable the middle button in your driver and/or Linux/Windows setup, if it can't be made to work reliably and correctly.

@dao , wdyt, as the tabbed browsing module owner?

! In D146854#4808728, @dao wrote:
Yeah, I agree with Gijs. I would suggest we move this bug to Core::Widget: Gtk to see if some kind of workaround could be added there. If that's not an option, perhaps we need to disable this behavior by default on Linux if it's true that this is a typical scenario with touchpads (personally, I'm mainly on Ubuntu using a laptop, and I haven't seen this). A hidden pref that only a few users will find should be considered the last resort option for this kind of problem.

going to morph this and move so the widget folks can investigate.

Type: enhancement → defect
Component: Tabbed Browser → Widget: Gtk
Product: Firefox → Core
Summary: Request an option to disable "close tab with middle click" feature → "close tab with middle click" feature is disruptive on touchpads where middle click is triggered unintentionally

If that's not an option, perhaps we need to disable this behavior by default on Linux if it's true that this is a typical scenario with touchpads

I hope there was an implied "on Linux [when a touchpad is detected]" there... it seems like it'd be very drastic and also likely quite controversial to disrupt established desktop user workflows.

Attachment #9277378 - Attachment is obsolete: true
Attachment #9277636 - Attachment is obsolete: true

Hope you can make it customizable, e.g. as an about:config preference.

I have no problems with my touchpad... But I find that binding middle-click to closing a tab is counter to the usual semantics of that input, namely opening something (open a URL from the clipboard or opening a link in a new tab).

(In reply to :Gijs (he/him) from comment #27)

Per discussion on the phab patch:

! In D146854#4807708, @Gijs wrote:

So honestly, this doesn't seem like the right trade-off to me.

what's the trade-off with having this as an option? I see this problem was already coded and solved, and this is denying it because...what might happen?

(In reply to richardson_devin from comment #30)

I see this problem was already coded and solved, and this is denying it because...what might happen?

Dão and I both explained this in comment 27 which you quoted:

(In reply to :Gijs (he/him) from comment #27)

I'm concerned that we're basically compensating for hardware/driver issues by adding a pref in Firefox. The pref is also hidden and so many/most people won't find it, and continue to be frustrated - but on the flip side, most people won't need it and as a result exposing it in about:preferences also doesn't seem like a good idea.

So honestly, this doesn't seem like the right trade-off to me. The same issues that people are annoyed about here would apply in other pieces of software, and indeed in other places in Firefox (e.g. middle-clicking bookmarks, links in-content, etc.)

ISTM the right fix is to disable the middle button in your driver and/or Linux/Windows setup, if it can't be made to work reliably and correctly.

@dao , wdyt, as the tabbed browsing module owner?

! In D146854#4808728, @dao wrote:
Yeah, I agree with Gijs. I would suggest we move this bug to Core::Widget: Gtk to see if some kind of workaround could be added there. If that's not an option, perhaps we need to disable this behavior by default on Linux if it's true that this is a typical scenario with touchpads (personally, I'm mainly on Ubuntu using a laptop, and I haven't seen this). A hidden pref that only a few users will find should be considered the last resort option for this kind of problem.

Basically, a hidden pref to compensate for a hardware or driver/OS defect isn't an effective solution. People who want this pref purely for reasons of choice likely won't find it if kept in about:config, and it isn't a common enough issue (and matches behaviour in other browsers) to justify adding it into the user-visible preference list (which is already cluttered enough as it is). Adding the code once (ie writing the patch) isn't the only cost for adding a feature like this, and Dão and I don't think the trade-off is worth it here.

I'm genuinely puzzled as to how this is getting dismissed as a hardware/os defect. Nearly every laptop one can purchase has a touchpad. Touchpads have vague (to the user) "regions" that represent left/middle/right clicks. If you happen to click near the boundary, you only have to be off by maybe a millimeter to go from a left click to a middle click. Accidental tab closures happen regularly for me (i.e., multiple times per day) on any laptop device I use.

The argument that "The pref is also hidden and so many/most people won't find it" is somewhat unpersuasive. Firefox has hundreds of hidden prefs already (probably largely unused and unrequested by anyone), so there doesn't seem to be any generalized hesitation to implement them. And people would find it, the same way that they find any of the other hidden prefs: by googling and finding the forum where someone has posted the answer.

Disabling the middle button entirely on the entire computer is not an option for many people, if the middle button is useful at other times outside of Firefox. Also, changing the entire system one uses just because of a flaw in a single application doesn't feel right to me. Finally, yes, accidental middle clicks do happen in other programs. Luckily for the most part, stray middle clicks do nothing in other apps, or at least do something inconsequential like raise a menu. Only in these browser tabs is it completely destructive and thus problematic.

You'll find the trade-off worth it the first time you are using a laptop and accidentally close something you were working on for an hour.

Summary:
a) It isn't a hardware issue/defect.
b) There is nothing wrong with a hidden pref. Firefox has a ton of them. People find them.
c) Disabling middle click system-wide is not an option for many people, and doesn't seem justified for one single problem app.
d) Bad bad bad things happen when stuff is accidentally closed.

It's pretty clear from the number of people in this thread and in other threads in other forums that accidental tab closures happen regularly and are causing problems for users.

Please add the option.

(In reply to RobL from comment #32)

The argument that "The pref is also hidden and so many/most people won't find it" is somewhat unpersuasive. Firefox has hundreds of hidden prefs already (probably largely unused and unrequested by anyone),

Exactly, which is why we don't want to encourage everyday end users to mess with hidden prefs. They're basically under-the-hood toggles that we use during the development process as well as a storage mechanism for profile data.

You'll find the trade-off worth it the first time you are using a laptop and accidentally close something you were working on for an hour.

Summary:
a) It isn't a hardware issue/defect.
b) There is nothing wrong with a hidden pref. Firefox has a ton of them. People find them.

Who's "people"? Is grandma gonna find them...? Using hidden prefs to solve user problems is just bad software design. If the problem is as real and widespread as you assert, we gotta find a different solution.

Severity: normal → S3

(In reply to Dão Gottwald [::dao] from comment #33)

The argument that "The pref is also hidden and so many/most people won't find it" is somewhat unpersuasive. Firefox has hundreds of hidden prefs already (probably largely unused and unrequested by anyone),

Exactly, which is why we don't want to encourage everyday end users to mess with hidden prefs.

I do understand why you feel that way, it certainly seems to make sense on the surface. Interestingly though, Mozilla themselves has gone to all the trouble to make a nice webpage that explains to users how to utilize about:config. Feel free to check it out for yourself, in the following easily accessible support link that everyday users can easily find, and which discusses not only searching for hidden prefs but modifying them as well. To be fair, it does say it is "recommended for advanced users only". I consider myself sufficiently advanced. :-)
https://support.mozilla.org/en-US/kb/about-config-editor-firefox

b) There is nothing wrong with a hidden pref. Firefox has a ton of them. People find them.

Who's "people"? Is grandma gonna find them...?

Well, I'm old enough to be a grandpa, so sure. Grandma, grandpa, aunt, uncle, nephew, 2nd cousin. Basically anyone with the wherewithal to google for an answer to a Firefox annoyance and who stumbles across the helpful forum posters who have posted the answer. I've used about:config a number of times for other issues, and if you google around, you'll see a very large number of other folks have as well.

Using hidden prefs to solve user problems is just bad software design.

I've always felt that Firefox made a brilliant decision to provide advanced settings for advanced users, while at the same time maintaining a simple and small set of preferences for novice users. It's as close to having your cake and eating it too as one might find in the software development world. The noobs are satisfied by not being intimidated with arcane settings, and the advanced users are satisfied by being able to have a bit more control. Seems pretty smart to me, I'm surprised you feel it is a flaw.

If the problem is as real and widespread as you assert, we gotta find a different solution.

If there is another solution I'd love to hear it. The other solutions proposed thus far (getting rid of the middle click feature entirely or putting an option in the normal settings pages) have already been shot down. The hidden pref change seemed like a reasonable compromise, and the coding has already been completed. It's just not being allowed to go forward due to reasons that I'm not fully understanding.

(In reply to RobL from comment #34)

If there is another solution I'd love to hear it.

(In reply to RobL from comment #32)

I'm genuinely puzzled as to how this is getting dismissed as a hardware/os defect. Nearly every laptop one can purchase has a touchpad.

With you so far.

Touchpads have vague (to the user) "regions" that represent left/middle/right clicks. If you happen to click near the boundary, you only have to be off by maybe a millimeter to go from a left click to a middle click.

Uh, no. I have never seen/used a laptop that supports middle clicks for touches on the touchpad. Touchpads with physical buttons underneath them including some kind of smaller middle click / scroll - sure. But not on the touchpad itself, with single-finger touches in some difficult-to-discern region. I have something like 8 laptops in this room with me, of varying ages and makes, and I do not recall this "feature" existing on any of them, certainly not on by default (and I never felt the need to go looking for it).

What kinds of touchpads are these? Is there configuration that has to happen, maybe in Synaptics' config tool or something? Is this on Linux (like the reporter) or Windows? Both? Are there visible markings on the touchpad to indicate which region is used for middle clicks? Even 1 example device would help...

What I'm trying to establish is whether we can detect this case. Because I would be quite happy to turn off middle-click-to-close-tabs by default on devices like this. But it would require being able to know we are in this situation, which to me is completely arcane. I'm sure that's my sample bias, but right now it's still impossible to tell.

What I'm trying to establish is whether we can detect this case. Because I would be quite happy to turn off middle-click-to-close-tabs by default on devices like this. But it would require being able to know we are in this situation, which to me is completely arcane. I'm sure that's my sample bias, but right now it's still impossible to tell.

I don't think disabling or enabling this behavior based on operating system or device is helpful since any or even multiple (external) input devices could be used at the same time regardless.

Uh, no. I have never seen/used a laptop that supports middle clicks for touches on the touchpad. Touchpads with physical buttons underneath them including some kind of smaller middle click / scroll - sure. But not on the touchpad itself, with single-finger touches in some difficult-to-discern region. I have something like 8 laptops in this room with me, of varying ages and makes, and I do not recall this "feature" existing on any of them, certainly not on by default (and I never felt the need to go looking for it).

What kinds of touchpads are these? Is there configuration that has to happen, maybe in Synaptics' config tool or something? Is this on Linux (like the reporter) or Windows? Both? Are there visible markings on the touchpad to indicate which region is used for middle clicks? Even 1 example device would help...

I'll gladly be a datapoint in your sample:
My Thinkpad P14s has a track-pad with integrated buttons (so invisible separation between the middle button, the track-pad itself or any of the buttons), three additional button's that are separated above the track-pad and then might have an external mouse connected (with a middle mouse button) sometimes.

I want to convey that I actually do use the middle mouse button integrated into the track-pad in multiple applications and I do unintentionally click the middle mouse button in that context as well, it's just that Firefox is the only application that has such a disruptive effect when it happens. I don't want to reconfigure the way my mouse works, I want to disable this disruptive effect.

When designing UX one should always consider the possibility of unintentional input. When the probability of unintentional input if high, the application should be forgiving and allow the user to undo any mistakes and try again. Considering web accessibility, I can imagine Firefox users that struggle with fine motor skills would benefit greatly from the possibility to configure this.

(In reply to remo.pas22 from comment #36)

Thanks for giving a concrete example.

might have an external mouse connected (with a middle mouse button) sometimes.

And then we shouldn't disable it. But that's also the kind of thing we have to take into account e.g. for on-screen keyboard support for touch-only devices which may or may not have a USB/bluetooth keyboard connected. It doesn't mean it can't be done, it just makes things a little trickier.

When designing UX one should always consider the possibility of unintentional input. When the probability of unintentional input if high, the application should be forgiving and allow the user to undo any mistakes and try again.

Which is why you can undo close tab with ctrl-shift-T, or using Firefox View (as of Firefox 106).

Another concrete example (the device I was using in my above comment 2 years ago) is an Asus Zenbook 13.

Because I would be quite happy to turn off middle-click-to-close-tabs by default on devices like this.

Applications should never behave differently in response to different hardware. I would go bananas if click input started working differently just because I plugged in another peripheral.

Please consider the accessibility standpoint: You do not and cannot know the types of disabilities people are trying to manage related to input. Applications must be flexible in ways that cannot be intelligently predicted by developers. I am a disabled user. I depend on software configuration to allow me to use programs effectively. Apps trying to be "smart" and remove flexibility are a nightmare.

Which is why you can undo close tab with ctrl-shift-T, or using Firefox View (as of Firefox 106).

If the tab state were preserved after cose this might be a good solution, but it very often results in losing context and the actual tab state being lost.

(In reply to evanm from comment #38)

If the tab state were preserved after cose this might be a good solution, but it very often results in losing context and the actual tab state being lost.

For concrete examples of this, please file specific bugs. Firefox can't restore tabs perfectly in the face of arbitrary, turing-complete web content that has been closed, but depending on the example maybe we can do better.

(In reply to evanm from comment #38)

Applications should never behave differently in response to different hardware. I would go bananas if click input started working differently just because I plugged in another peripheral.

I'm confused by this sentiment, because apps do this all the time, and wouldn't be very usable if they didn't. You switch screens, Firefox display density changes so things aren't impossible-to-use tiny/huge, and session-restored Firefox windows fit on your laptop screen even if they were previously positioned on an external screen that is no longer connected. You switch input devices, the on screen keyboard can be turned on/off (so it's not in the way, or impossible to type because you have no input device). You switch printers, the available paper sizes change. You use touch input to open menus, we give you more padding between items so they're easier to activate accurately.

To be clear, ideally we would be able to detect the source of an event as touch vs. a connected external mouse, but I'm not sure that's possible at the JS-exposed DOM level right now - though perhaps that's fixable. It would depend on how these events arrive at the OS level.

Priority: -- → P3
Assignee: github-12-2017-ds8 → nobody
Status: ASSIGNED → NEW

If adding a hidden pref is not an option,
then please consider other options. For
example just disable that feature completely
and provide an extension to re-enable
(which already does exist btw, afaics).

It looks quite simple: you introduced some
"feature" that half of users now hate and a
few do like, others do not care.
You probably expected no one will hate it, or
maybe everyone is going to like it, but this
isn't happening. So the simplest is to please
disable it by default.

I imagine that would reflect very poorly on Firefox's PR, given that Chrome would still be offering it as a core feature for anyone and everyone who has physical mouse buttons and would fight to keep it (myself included).

I could just as readily argue that your concerns aren't valid enough for in-core support and the status quo which favours my hardware setup should be preserved.

Heck, my mother doesn't know how to install Firefox extensions, but she makes heavy use of middle-clicking to open new tabs.

I could just as readily argue that your concerns aren't valid enough for in-core support and the status quo which favours
my hardware setup should be preserved.
"preserved" but I thought its a recent feature,
is it not?

Heck, my mother doesn't know how to install Firefox extensions, but she makes heavy use of middle-clicking to open new tabs.
How is the use of "middle-clicking to open new tabs"
even related to that discussion?

I could just as readily argue that your concerns aren't valid enough for in-core support and the status quo which favours
my hardware setup should be preserved.

"preserved" but I thought its a recent feature,
is it not?

Heck, my mother doesn't know how to install Firefox extensions, but she makes heavy use of middle-clicking to open new tabs.

How is the use of "middle-clicking to open new tabs"
even related to that discussion?

(In reply to Stas Sergeev from comment #43)

"preserved" but I thought its a recent feature,
is it not?

Middle clicks have closed tabs since at least 2007 (15 years), judging by old code, and probably longer but I don't have the time to dig around in the old CVS repository for history beyond 2007. So no, it's not recent.

If adding a hidden pref is not an option, then please consider other options.

That is what we're doing, see earlier comments.

(In reply to :Gijs (he/him) from comment #39)

(In reply to evanm from comment #38)

If the tab state were preserved after cose this might be a good solution, but it very often results in losing context and the actual tab state being lost.

For concrete examples of this, please file specific bugs. Firefox can't restore tabs perfectly in the face of arbitrary, turing-complete web content that has been closed, but depending on the example maybe we can do better.

Thank you. I really do appreciate the offer, but I agree with you that "reopen closed tab" is too imperfect to be a good substitute due to the complexity of dynamic web content.

(In reply to evanm from comment #38)

Applications should never behave differently in response to different hardware. I would go bananas if click input started working differently just because I plugged in another peripheral.

I'm confused by this sentiment, because apps do this all the time, and wouldn't be very usable if they didn't. You switch screens, Firefox display density changes so things aren't impossible-to-use tiny/huge, and session-restored Firefox windows fit on your laptop screen even if they were previously positioned on an external screen that is no longer connected. You switch input devices, the on screen keyboard can be turned on/off (so it's not in the way, or impossible to type because you have no input device). You switch printers, the available paper sizes change. You use touch input to open menus, we give you more padding between items so they're easier to activate accurately.

To be clear, ideally we would be able to detect the source of an event as touch vs. a connected external mouse, but I'm not sure that's possible at the JS-exposed DOM level right now - though perhaps that's fixable. It would depend on how these events arrive at the OS level.

I was also surprised by your answer and I spent some time thinking about why. I think there is a fundamental difference between rendering to a specific device with variable features, and accepting input from a generic source such as mouse clicks. It has to do with the inherent contract provided by the underlying operating system.

Different screens and printers render differently, of course. These differences are explicitly exposed to applications, by design.

Mouse devices are not exposed in this fashion. We are expected to use defined interfaces which provide mouse events, such as Wayland/x11. The details of the input device are hidden by design. Firefox typically does not have permission to access /dev/input/mouse* at all. It would be unexpected for an application to attempt to behave differently because this would violate the design precepts of the windowing/operating system. Users expect to be able to change the windowing system configuration to remap and modify input events according to their need. There is an implicit contract around this abstraction, and this contract is extremely important for people (like me) who have modified their input systems to help manage their accessibility needs.

Middle clicks have closed tabs since at least 2007 (15 years)

Long enough for ppl to defend "existing setups",
so how about an extension to un-extend and
disable that?

That is what we're doing, see earlier comments.

I've seen that, but I don't think that route will
bring us some fruits in a near future. Detecting
the device type is probably a big work for low
benefit. Since this feature annoys quite many
users and to a high degree of annoyance, I would
just propose to provide an extension to quickly
disable and forget. Or maybe some existing UI
tweaker extension should be enriched with that
control. Its definitely not something that can
lurk around for years, so something very quick
and simple should be done about it imho.

(In reply to Stas Sergeev from comment #43)

How is the use of "middle-clicking to open new tabs"
even related to that discussion?

Sorry. I'm running on half a night's sleep while I wait for some melatonin to kick in and I fell into muscle memory without noticing. (I write about middle-click to open behaviour much more often than middle-click to close because so many sites break it.)

(In reply to Stas Sergeev from comment #43)

Heck, my mother doesn't know how to install Firefox extensions, but she makes heavy use of middle-clicking to open new tabs.

How is the use of "middle-clicking to open new tabs"
even related to that discussion?

Oh, but it is VERY relevant to the discussion - and much in favor of your point, actually.

"Middle-clicking opens stuff in a new tab" is a concept that is easily internalized.
"... EXCEPT when clicking on tabs, in which case it does exactly the OPPOSITE" is a concept that is NOT easily internalized.

It is INFURIATING how reluctant the developers are to even ACKNOWLEDGE that the people who feel like this have a VERY VALID point.

Unfortunately, if such a behavior was there
for 15 years, acknowledging won't help. There
would always be a valid question to us: why
haven't you complained 15 years ago? Me -
because I used FF only from PC 15 years ago,
not from notebook... So I simply didn't know
about that feature at all. I would never even
find it out w/o working from notebook.
So while an essentially evil feature, the fact
that no one even noticed for 15 years, doesn't
suggest like its going to be acknowledged or undone.
So imho the extension (either new or enrichment
to some existing UI tweaker) would be adequate
in a short run.

(In reply to Christoph Lipka from comment #48)

(In reply to Stas Sergeev from comment #43)

Heck, my mother doesn't know how to install Firefox extensions, but she makes heavy use of middle-clicking to open new tabs.

How is the use of "middle-clicking to open new tabs"
even related to that discussion?

Oh, but it is VERY relevant to the discussion - and much in favor of your point, actually.

"Middle-clicking opens stuff in a new tab" is a concept that is easily internalized.
"... EXCEPT when clicking on tabs, in which case it does exactly the OPPOSITE" is a concept that is NOT easily internalized.

It is INFURIATING how reluctant the developers are to even ACKNOWLEDGE that the people who feel like this have a VERY VALID point.

If I remember correctly, last I used Konqueror, it defaulted to "middle-click on a tab opens a new tab which submits the contents of the clipboard to a search engine".

It was one of the most surprising, confusing, and frustrating UI behaviours I'd ever encountered when I discovered it, and, being someone technically skilled enough to have installed Linux on my own PC in the 2000s, the first thing I did was to dig around until I figured out how to turn it back to the more intuitive "Middle-clicking something that wouldn't normally spawn a new tab opens a tab. Middle-clicking that new tab reverses the process."

"Middle-clicking something that wouldn't normally spawn a new tab opens a tab. Middle-clicking that new tab reverses the process."

"reverses the process" means to close (mistakenly
created) empty tab.
It would be perfectly fine if it'd close only empty tabs,
but its not what it does.

(In reply to Stephan Sokolow from comment #50)

If I remember correctly, last I used Konqueror, it defaulted to "middle-click on a tab opens a new tab which submits the contents of the clipboard to a search engine".

It was one of the most surprising, confusing, and frustrating UI behaviours I'd ever encountered when I discovered it, and, being someone technically skilled enough to have installed Linux on my own PC in the 2000s, the first thing I did was to dig around until I figured out how to turn it back to the more intuitive "Middle-clicking something that wouldn't normally spawn a new tab opens a tab. Middle-clicking that new tab reverses the process."

See? That's where our brain-wiring differs: I do NOT expect the "reverses the process part" (which, I presume, you only acquired because FF behaves like this and you made liberal use of it); instead my expectation is instead "operates correspondingly".

But you can see how annoying it is when such expectation is broken, right?

Wouldn't you consider it even MORE annoying - bordering on INFURIATING - when the expected behavior cannot be undone by a maneuver as obvious, well-trained and reliable as closing the unexpectedly opened tab (usually as easy as a single left-click on the "x"), but instead requires the use of a (to some) somewhat obscure feature that is less accessible, and on top of that does NOT always work reliably?

Unfortunately I am NOT in your shoes that I would be able to mend the issue myself, or I would ABSOLUTELY POSITIVELY do it.

If the solution is to be an optional extension, then SO BE IT, but please SOMEONE FRIGGIN' IMPLEMENT IT - though I have no clue how this would be any better than a hidden setting; if the argument is "people can't google how that setting would be called and how to activate it", then let me tell you that I for one am much more familiar and comfortable with googling the name of a hidden setting and twiddling it, than I am with installing FF extensions.

Can't you devs see that although the people disliking this behavior may be just a minority, those users are SERIOUSLY FRUSTRATED by it? Do you think that is in your interest in any way? ANGRY users??

Defect (or alleged defect) management is not just about how many users are affected - but also about how severely they are affected.
To users not familiar with this behavior, in some situations it can have just as severe consequences as a TOTAL CRASH of the application - DO YOU DEVS NOT SEE THAT??!

(In reply to Christoph Lipka from comment #52)

I can sympathize, but, honestly, I see it as a flaw in the touchpad, same as how I always turn off tap-to-click because palm rejection is never as good as they claim.

...especially now that the behaviour Firefox may have originated (did Opera do it first?) has become a pseudo-standard. I think GIMP and Arduino IDE are the only applications I have installed where "documents/views are represented as tabs" doesn't get paired with "middle-click closes tabs".

Just out of the applications I have installed, middle-click closes tabs in Audacious, Chromium, Dolphin, Featherpad, Firefox, Godot, gVim, Konqueror, Konsole, Krita, LibreSprite (and, thus, probably ASEprite from which it was forked), LyX, Okteta, PCManFM, PCManFM-Qt, Pidgin, Pixelorama, Thunderbird, Yakuake, and Zeal.

(In reply to Stephan Sokolow from comment #53)

(In reply to Christoph Lipka from comment #52)

I can sympathize, but, honestly, I see it as a flaw in the touchpad, same as how I always turn off tap-to-click because palm rejection is never as good as they claim.

It is NOT a tochpad issue - ABSOLUTELY POSITIVELY NOT.

I am using a regular mouse, and yet the behaviour keeps getting in my way. Simply because it constitutes a SEVERE INCONSISTENCY IN THE UI.

Yes, there IS a flaw in (some) touchpads that can cause you to run into the issue - but there is also a flaw in the UI itself that can cause you to suffer from the same symptoms.

Addressing this problem as a UI issue would also automatically address the touchpad issue side of it. The converse is NOT true.

I can sympathize, but, honestly, I see it as a flaw in the touchpad

While touchpad definitely has the flaw
here, the feature itself is flawed too.
And is seriously flawed.
Previously there was a button with the
cross, on which you needed to explicitly
click to close. And even in that case you
could opt for a confirmation dialogue as
even the button clicks can happen by mistake.
Now you have that large empty area and
tab gets just closed when you click anywhere
on that... And there seem to be no way to
opt in for a confirmation prompt.
Tell me, you've found no better usage for
such a large free area, but to use it all for
such a dangerous operation as closing is?
Come on.

Just out of the applications I have installed, middle-click closes tabs in

In that case it should be handled by WM
and is configured on a WM level. It just
doesn't work to configure this out separately
for every app.

(In reply to Christoph Lipka from comment #54)

I am using a regular mouse, and yet the behaviour keeps getting in my way. Simply because it constitutes a SEVERE INCONSISTENCY IN THE UI.

Except that, as I just said, the behaviour has become a de facto standard, implemented by the overwhelming majority of "tabs as documents" applications I'm aware of... at least here on Linux.

I do NOT want Firefox making itself even more divergent from platform conventions, unofficial or otherwise.

As one example, it's bad enough that they "improved" things by making it necessary to ignore the by-default auto-selection in the address bar and triple-click to get Firefox to populate the SELECTION clipboard (it took me a while to retrain that muscle memory), in the process making it more awkward to select part of a URL.

(In reply to Stas Sergeev from comment #55)

Tell me, you've found no better usage for
such a large free area, but to use it all for
such a dangerous operation as closing is?
Come on.

Actually, I find it very necessary for several reasons. The main two are:

  1. The X only appears when the tab has focus, which is something I wouldn't want to change because I set my tabs to shrink down to icons if necessary. (Partly as a workaround for Firefox not supporting "scroll wheel switches tab focus, even when they're overflowing")
  2. Fitts' law says that the bigger a region is, the easier it is to put your pointer in it.

Closing is only dangerous because people like the Firefox devs are treating the onbeforeunload event like media autoplay and, longer-term, want to kill it off entirely, because, apparently, "Are you sure?" popups are inherently too dangerous for grandma to be seeing, even with non-customizable text, and, if a site doesn't reinvent the "continuous auto-save" wheel, that's the site's fault.

I really feel like we aren't asking for a lot here. A bunch of people that would really like to be just browsing the web are frustrated to the point where they find themselves arguing on a bug-tracker.

It's not a hardware problem. The accidental clicking is not the actual issue (I miss-press button's on all kinds of hardware all the time), the issue is the behavior or the lack of configuration options to change said behavior.

Could we consider a in-between solution that could make (most?) people happy:

  • Providing a setting that enables a confirmation when middle clicking to close a tab.

That would seem logical since within the Tabs settings, Firefox provides these out of the box:

[ ]  Confirm before closing multiple tabs
[x]  Confirm before quitting with Ctrl+Q

Aren't these settings solving the exact same category of problems that we are discussing here? Now grandma doesn't have to go digging in hidden prefs, just plain settings.

My preference still would be to be able to disable it outright but since that apparently is not a valid solution according to the comments above, this would make a very helpful alternative.

The X only appears when the tab has focus, which is something I wouldn't want

You can do rclick and get a menu pop-up,
which has Close among other things. This
is the right and good way of doing things:
if GUI doesn't know why you did an rclick,
it asks what to do with a menu. Definitely
mclick could do something as interesting
instead of duplicating what is achieved by
many other ways.

if a site doesn't reinvent the "continuous auto-save" wheel, that's the site's fault.

No its not.
Next time someone adds a reboot action
on a right-click on an empty desktop space.
Why would anyone click an empty desktop
space? There are no short-cut icons so
clicking is useless, lets use it for reboot,
why not. :)
In fact you could bind some actions on
a click to empty desktop space. But reboot
is definitely not one of those.
Likewise, bind something good and safe
to your middle-click on a tab and make
everyone happy. Don't bloat firefox or sites
to make an undo of that (tab restore) easier,
it doesn't help. Even going to the restore menu
every time is already annoying enough to not
even consider that as an option.

(In reply to Stas Sergeev from comment #58)

The X only appears when the tab has focus, which is something I wouldn't want

You can do rclick and get a menu pop-up,
which has Close among other things. This
is the right and good way of doing things:
if GUI doesn't know why you did an rclick,
it asks what to do with a menu. Definitely
mclick could do something as interesting
instead of duplicating what is achieved by
many other ways.

Yeah, let's double the number of clicks it'll take. No. Just no.

I'd be more likely to come up with something similar to this old hack of mine, but for remapping middle-clicks into a left click and a Ctrl+W rather than for catching and discarding Ctrl+Q in the days before the now-existing "Are you sure?" dialog.

if a site doesn't reinvent the "continuous auto-save" wheel, that's the site's fault.

No its not.

I agree. That's my paraphrasing of the rationale given by Firefox developers on the Bugzilla bug about deprecating and removing onbeforeunload.

Yeah, let's double the number of clicks it'll take. No. Just no.

I don't understand why to minimize
the amount of close clicks. Do you
want to minimize the amount of reboot
clicks?
I.e. if you need to do multiple clicks to
open URL, then your performance degrades.
So we need to open URL by 1 click, that's
clear. But what degrades if you don't close
a tab in 1 click? Likewise no one expresses
the problem of not having a reboot in 1 click.

But if we are to invent something new, then
what to bind on a mclick? Well, pop-up menu
is already on an rclick. So you can bind new
functionality to that mclick by the key modifiers.
Eg hold Ctrl and mclick to the tab, and it
closes. Hold Alt and mclick, and something
else is done. This is an example of more efficient
usage of an existing space and actions. There
are definitely many other ways to bind something
useful, including close, in a useful ways.
What was done, was done in a worst possible
way.

But if we are to invent something new, then
what to bind on a mclick?

Konqueror already tried that and it played merry hell with my muscle memory back in KDE 3.5.x.

The only options that don't play merry hell with muscle memory are:

  1. Middle-click closes tabs, remaining consistent with over 90% of the applications I had available to test (And, given that I only had 23 applications which have closable tabs to test, I suspect the percentage is much higher once you've got a statistically significant sample size rather than just "21 out of the 23 document-tabbing applications I have use middle-click to close tabs".)
  2. Middle-click does nothing

An option to make middle-click do nothing in Firefox for users who accidentally middle-click is something I'm fully in favour of, as long as I can keep it the same for me.

In theory, there's nothing wrong with allowing rebindable tab middle-click, but that's more in line with the KDE philosophy of UI customization than the Mozilla philosophy. Mozilla has refused to implement and maintain UI customizations much more "mainstream-able" than redefining tab middle-clicking.

(In reply to :Gijs (he/him) from comment #31)

(In reply to richardson_devin from comment #30)

I see this problem was already coded and solved, and this is denying it because...what might happen?

Dão and I both explained this in comment 27 which you quoted:

(In reply to :Gijs (he/him) from comment #27)

I'm concerned that we're basically compensating for hardware/driver issues by adding a pref in Firefox. The pref is also hidden and so many/most people won't find it, and continue to be frustrated - but on the flip side, most people won't need it and as a result exposing it in about:preferences also doesn't seem like a good idea.

So honestly, this doesn't seem like the right trade-off to me. The same issues that people are annoyed about here would apply in other pieces of software, and indeed in other places in Firefox (e.g. middle-clicking bookmarks, links in-content, etc.)

ISTM the right fix is to disable the middle button in your driver and/or Linux/Windows setup, if it can't be made to work reliably and correctly.

@dao , wdyt, as the tabbed browsing module owner?

! In D146854#4808728, @dao wrote:
Yeah, I agree with Gijs. I would suggest we move this bug to Core::Widget: Gtk to see if some kind of workaround could be added there. If that's not an option, perhaps we need to disable this behavior by default on Linux if it's true that this is a typical scenario with touchpads (personally, I'm mainly on Ubuntu using a laptop, and I haven't seen this). A hidden pref that only a few users will find should be considered the last resort option for this kind of problem.

Basically, a hidden pref to compensate for a hardware or driver/OS defect isn't an effective solution. People who want this pref purely for reasons of choice likely won't find it if kept in about:config, and it isn't a common enough issue (and matches behaviour in other browsers) to justify adding it into the user-visible preference list (which is already cluttered enough as it is). Adding the code once (ie writing the patch) isn't the only cost for adding a feature like this, and Dão and I don't think the trade-off is worth it here.

I dont see any trade off here. If your answer is it shouldnt exist because people might not find it, well that's already the issue, people can't find it. That's the current situation, the only difference right now is no one CAN find it. Having it available to find is only a gain, nothing is lost. I feel like your reasoning could be used for every setting, every possible customization option that already exists, its basically saying nothing.

I also have no idea why anyone would bring up clutter, about:config is search based. No one's scrolling through all of the configuration options, I searched for middleclick, and there is ONE result. And it's really bizarre what that one result is, and that this option is being fought against, I encourage you to search and see it yourself.

I also do think that "likely won't find it if kept in about:config"
argument is just an excuse for not doing anything at all.
You could quickly help people who CAN find it
(and believe me, this horrible "feature" will force
many people to find that pref anywhere), and then
keep discussing other ways of solving it, like pretending
its a "hardware or driver/OS defect" and whatever.
Just adding a config switch for those who REALLY need
it, doesn't obligate you to anything. Doesn't mean that
any other solution should not be kept discussed or
implemented, etc. And it doesn't even take much efforts
or time. Why not to do just that and keep discussing
forever any other solution you think suits?

(In reply to :Gijs (he/him) from comment #44)

(In reply to Stas Sergeev from comment #43)

If adding a hidden pref is not an option, then please consider other options.

That is what we're doing, see earlier comments.

What about the option described in comment #57 (https://bugzilla.mozilla.org/show_bug.cgi?id=1439247#c57)?

I would like to cast my vote for making "middleclick does not close tab" a about:config option.

I agree with those who say it's too niche for about:preferences.

I do NOT agree that "no one will find it" in about:config, Just like 100 other issues that people search the web for and find an answer in about:config, this appears to me in EXACTLY the same category.

For example, right now, I have

accessibility.browsewithcaret
browser.tabs.insertAfterCurrent
browser.tabs.warnOnClose

set in about:config. This middleclick close tab seems like it's in exactly the same category.

And for me it's not a general windows thing or device thing. It's that I click on the tab with 3 fingers instead of 2 because of my (mis-)habits. I have windows 10 three finger click defined to be middle click. I use middle-click all the time to open a tab in a new window. So I have muscle memory. So I click 3-finger instead of 2-finger on the tab when I want to see the context menu by mistake. This is entirely an unusual user customization situation which I think about:config is precisely designed for.

So I join my voices with others here to add this in about:config.

Thanks!

The superuser post:
https://superuser.com/questions/113048/how-do-i-prevent-firefox-from-closing-tabs-on-middle-click
mentioned above was one of the top search results for me on this issue.
It links here, FYI.

I keep loosing work due to accidentally closing of tabs.
Previously I've already disabled the swipe for back/forward history config option widget.disable-swipe-tracker which had a similar effect.

This behavior is beyond disruptive. Please put something in about:config to address this. I can understand the utility if you're using a full sized mouse and it can reasonably be turned on by default. It is unreasonable to not address that people want to be able to shut this feature off completely. I should be able to remap middle-click to left click on a device where the touch pad has a significant middle-click zone so inadvertent middle clicking does not close my tab. I closed a Teams meeting tab mid-discussion with someone which was very disruptive.

Okay, will look at it.

Flags: needinfo?(stransky)

Bug 1539998 may be related.

See Also: → 1539998

It may be possible to get pointer type from OS (mouse vs. touchpad) and disable middle click event for such device. Not sure if we can get info about emulation.

Looks like it's not easy to check if the button event comes from touchpad. Both X11/Wayland reports event source as mouse, tested on two laptops. That's confusing as Gtk itself uses touchpad source id.

Assignee: nobody → stransky
Status: NEW → ASSIGNED

Better to provide the pref, other options are more complicated. Get touchpad event status is not easy, it may involve wayland event investigation and wl_seat capabilities inspection and may not be reliable. I don't know how to get reliably such info either. Disabling middle mouse button on OS level is tricky, I've found X11 solution only so Wayland may not be covered.

Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/7e0cd6e234ec [Linux] Allow to disable middle mouse button events by pref r=emilio

Thanks, stransky.

Ideally in firefox about:config, middle-click could be assigned to whatever behavior the user wanted. I, myself, would assign it to "right-click." However the option to turn it off in about:config would also help my particular use case. As would providing a confirmation on close-by-middle-click (https://bugzilla.mozilla.org/show_bug.cgi?id=1439247#c57).

(In reply to john v kumpf from comment #76)

Thanks, stransky.

Ideally in firefox about:config, middle-click could be assigned to whatever behavior the user wanted. I, myself, would assign it to "right-click." However the option to turn it off in about:config would also help my particular use case. As would providing a confirmation on close-by-middle-click (https://bugzilla.mozilla.org/show_bug.cgi?id=1439247#c57).

Button assignments are covered by Bug 1539998. It reads config from GNOME right now, we may implement it for KDE too.

Flags: needinfo?(stransky)

I suggest the title should be changed from:

"close tab with middle click" feature is disruptive on touchpads where middle click is triggered unintentionally

to:

"close tab with middle click" feature is disruptive when middle click is triggered unintentionally, eg on touchpads where middle click easy to hit by accident.

Because it's not about touchpads, strictly, it's about any unintentional middle-click, as the discussion above explains.

Folks are trying to pull teeth now just to make sure to only fix this issue for touchpad users.

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 125 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: