187199 - Disable double-click for tab close button

Status: RESOLVED WONTFIX

(SeaMonkey :: Tabbed Browser, enhancement)

Description

[David Mediavilla]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; es-AR; rv:1.2.1) Gecko/20021201
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; es-AR; rv:1.2.1) Gecko/20021201

It happened several times to me that while intending to close one tab I actually
close two. Probably I send a double click instead of a single click (or is a
false keyup event appearing?). So I suggest that the tab close button should
catch and ignore double clicks while accepting single-clicks.

Reproducible: Couldn't Reproduce

Steps to Reproduce:
1. Try to close on tab by single clicking on the rigthside X button
2. The current tab closes
3. The next tab becomes current and it is closed without me having an
opportunity to see it.

Actual Results:  
Two tabs are closed instead of just one.

Expected Results:  
Colse just the current tab.

Theme: GrayModern

Comment 1

[Jason Bassford]

I'll go a long with this one, it makes sense.

Comment 2

[Prognathous]

Ignoring double clicks would be inconsistent with the OS. For example, try the
following test in Windows:

1. Open two windows of any application (Windows Explorer will do)
2. Maximize both windows
3. Double click the close-window widget

Result: Both windows will close

This is in line with what I expect Mozilla to do if I quickly press the close
widget button twice -> close two tabs. Actually, I do this quite often when
closing several tabs (that is, press the close widget multiple time, something
that Mozilla could interpret as double clicks)

This bug is invalid, IMHO.

Prog.

Comment 3

[Jason Bassford]

Sure, but if you want to go the Windows example route, try double-clicking on a
desktop shortcut.  What happens?  The application is only launched once, not
twice, so Windows ignores the double-click in that case.  In short, Windows is
inconsistent so it's up to us to implement the solution that makes the most
sense.  Since this is to prevent accidental dataloss, I say in makes more sense
to mirror Windows behaviour w/r/t shortcuts and ignore the double-click.

Comment 4

[Prognathous]

We are talking about close window/tab widgets, not about launching shortcuts. In
this aspect, Windows is totally consistent - double clicking the close-window
widgets of two stacked windows *always* closes both, and that's the behavior
that users expect.

Prog.

Comment 5

[Lewis Jardine]

1. Open two documents in tabs in Microsoft Visual Studio 2003 (the only
Microsoft app I can think of that uses tabs)
2. Double click the close-tab widget
Result: One tab will close

1. Open two documents in tabs in Microsoft Visual Studio 2003 (the only
Microsoft app I can think of that uses tabs)
2. Click the close-tab widget twice
Result: Two tabs will close

1. Open two windows of Explorer in Microsoft Windows XP
2. Maximize both windows
3. Double click the close-window widget
Result: One window will close

1. Open two windows of Explorer in Microsoft Windows XP
2. Maximize both windows
3. Click twice in the area the close-window widget takes up
Result: Both windows will close - the top window catches the first click; the
bottom the second.

1. Minimise all windows in Microsoft Windows XP
2. Position the pointer over the 'my computer' icon
3. Double click
Result: An Explorer window will open

1. Minimise all windows in Microsoft Windows XP
2. Position the pointer over the 'my computer' icon
3. Click twice
Result: The icon becomes selected, but no window opens.

There is a difference between clicking twice, and double-clicking. Typically
this can be set in the mouse control panel. The more of a 'power user' you are,
the faster you will have your double-click speed set, and thus the faster you
can single-click without it being interpreted as a double click. For everything
but mozilla's close tab widget, double-clicking activates one close widget once. 

Erroneous double-clicks can often occur when the mouse button is wearing out. In
many cases (laptops, server keyboards, etc.) it can cost over £200 for a new
mouse button. This behaviour is not much of a problem in every other
application, as the operating system can be set to interpret the erronious two
clicks as a double click (as opposed to two single clicks), and most widgets
behave the same whether they are single or double clicked. I can count on one
hand the widgets that activate twice when double-clicked (Scrollbars, and the
dropdown arrows of comboboxes spring to mind. Buttons certainly don't do this.)
To have such a non-standard behaviour, especially for a widget as powerful as
the close button, is rather annoying.

--

To be clear, double-clicking close buttons, as described in comment 4, _always_
activates one close button once. If you activate one close widget twice (as is
possible in Visual Studio .net 2003), or two close widgets once (as is possible
with two maximised windows on top of each other), you're clicking too slowly
(conversely, if fewer windows close than you expect, you have your double click
speed set too slow). Windows is entirely consistent, it is mozilla that is
behaving unexpectedly.

Jason, I assume that in comment 3 you're describing Windows' behaviour in
"single click to open an item" mode? By default, double-clicking a shortcut
opens it once; single-clicking it merely selects it.

Comment 6

[Jason Bassford]

> you're describing Windows' behaviour in "single click to open
> an item" mode? By default, double-clicking a shortcut
> opens it once; single-clicking it merely selects it.

Correct.  I apologise for not being specific enough.

However, just to confuse the issue even more, if you're using the Quick Launch
bar in Windows (XP specifically, but I believe this also applies to other
versions that have it) double-clicking a shortcut there *will* open the shortcut
twice.

Comment 7

[Mike Kaply [:mkaply]]

Not OS/2 specific

Comment 8

[Jesse Ruderman]

> 1. Open two windows of Explorer in Microsoft Windows XP
> 2. Maximize both windows
> 3. Double click the close-window widget
> Result: One window will close

I hate that behavior -- it's inconsistent with the rest of Windows and it slows
me down a lot.  I think it's due to Explorer being slow to close, not due to
special checking for double-clicks.  I can't reproduce that behavior right now.

Comment 9

[Lewis Jardine]

> I hate that behavior -- it's inconsistent with the rest of Windows

No it isn't - try, for instance, 

1. Open two copies of notepad in any windows
2. Maximize both windows
3. Double click the close-window widget
Result: One notepad will close; the one underneath remains open

Because notepad closes much faster than explorer, you have double-click rather
quickly to send a double-click to the top notepad rather than one click to each,
but if you succeed in double-clicking the close widget, the behaviour is the same. 

I can't think of a single windows application that does not exhibit this
behaviour; I'd welcome examples of any (apart from Mozilla's close tab widget :)
that differ.

Comment 10

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 11

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 12

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 13

[severinbreuer]

@Lewis Jardine: Windows most assuredly does not take a double-click on a close-window widget to mean the same thing as a single-click. If you mess around with your double-click speed in your Mouse control panel applet, this is abundantly clear. When it's on the "slowest" setting, click on the program icon in the upper left corner of a window; notice the lag between the time you click and when the system menu appears. This is because Windows is waiting for the double-click timeout to pass before it performs a single-click action. If you click on the close-window widget, however, the window will close almost instantly. This is because there is no defined double-click action for the close-window widget, so Windows doesn't wait around to see if you're going to double-click. If there was a defined action (e.g., if it was defined as being the same as a single-click, i.e. "close window"), then you'd see the same lag between click and close as you did with the system menu.

If a double-click *appears* to be the same as a single-click on the close-button widget, it is solely because the program in question hasn't closed fast enough for your second click to hit the second window's close-window widget. It is *not* because you didn't double-click fast enough, because when there *is* a defined double-click action, Windows will always wait until the double-click timeout expires before it carries out the single-click action. 

Nonetheless, windows is consistent: when in Explorer (this includes the Desktop), a single-click selects and a double-click opens; when in menus and toolbars, a hover selects, a single-click opens, and a double-click opens twice. Again, this is because there's no defined double-click action for a menu or toolbar item, so Windows doesn't bother to wait and see if you're single- or double-clicking: the instant you click once, it sends the command, and when you click again it sends the command again.

Comment 14

[severinbreuer]

I actually don't use SeaMonkey, but I think David Mediavilla's problem is due to the auto resizing of the tabbar when tabs are closed. In Firefox if you have a large number of tabs open the tabs themselves are resized to squeeze onto the tabbar. When you close the one such tab by clicking on its close button, the tabs instantly resize to fill the tabbar, which can mean that another tab's close button is now where the previous tab's button was. Thus, when you accidentally double-click, the first click closes the first tab, the second tab takes focus, and the second click closes that tab.

As I've pointed out above, contrary to suggestions otherwise, this is entirely consistent with the OS, and with every other program I've ever used within Windows. However, I agree users often slip up and accidentally double-click when they only mean to do it once, so it would perhaps make sense to implement a "detect accidental double-clicks" option. On the other hand, we have "Undo Close Tab" for users who accidentally or prematurely close tabs. Perhaps adding an "Undo Closed Tab" button (with an about:config setting to remove it!) next to the "Open a new tab" button in the tabbar would be the best solution?

Comment 15

[severinbreuer]

David Mediavilla tried to comment with the following but got an error message, so he emailed me to ask me to post his comment: <blockquote>I don't use SeaMonkey anymore, but Firefox set so that there is a close button on the right of the tabs line.
Sometimes I close tabs with it and sometimes with a middle click on the tab.

I don't remember the details of this specific problem, but I know I have used Undo Close Tab several times.</blockquote>As an aside, heh, I completely neglected to notice the dates on this thread before I commented (I was searching for bugs matching a problem I was having). Sorry to all who got emails about a six-year-old comment thread :)

Comment 16

[:Hb]

As said: We have Undo Close Tab now. WONTFIX.