Closed Bug 649216 Opened 13 years ago Closed 11 years ago

Remove unnecessary delay when clicking tab close buttons sequentially

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 23
Tracking Status
firefox5 - ---

People

(Reporter: fryn, Assigned: fryn)

References

Details

(Whiteboard: [Snappy:P2])

Attachments

(1 file, 1 obsolete file)

Attached patch patch (obsolete) — Splinter Review
After the patch for bug 465086 lands, it will be easy to close many tabs in quick succession without moving the cursor. Unfortunately, these clicks will fall into the default double-click threshold and trigger our double-click-blocking code.

Steps to reproduce:
1. Close a tab.
2. The newly selected tab's close button slides under the cursor. This takes approximately 250 milliseconds.
3. Try to close that tab immediately.

Expected results:
It closes.

Actual results:
It doesn't.

To fix this, we simply need to update a few lines of our double-click-blocking code.

CC'ing Dao, since he wrote the latest revision of that code.

---

Another issue is that the region taken up by the closing-tabs-spacer doesn't accept double-clicks to open a new tab.

To fix this, we can simply set .closing-tabs-spacer { pointer-events: none; }
Attachment #525268 - Flags: review?(gavin.sharp)
Attachment #525268 - Flags: review?(dao)
Summary: Make double-clicking on tabs and tab bar work better after bug 465086's patch → Make clicking quickly at the same location to close multiple tabs work
Summary: Make clicking quickly at the same location to close multiple tabs work → Make clicking quickly at the same location to close multiple tabs actually work
Attached patch simplified patchSplinter Review
Removed the CSS bit for the double-clicking on empty space of tab bar, since I fixed that in bug 465086's patch.
Attachment #525268 - Attachment is obsolete: true
Attachment #525268 - Flags: review?(gavin.sharp)
Attachment #525268 - Flags: review?(dao)
Attachment #525277 - Flags: review?(gavin.sharp)
Attachment #525277 - Flags: review?(dao)
Assignee: nobody → fryn
Status: NEW → ASSIGNED
Er, those should be double quotes in that patch. I'll fix that after it gets a review pass.
I think we want to be really, really careful here to ensure that we don't end up making it *harder* to double click elsewhere, which is frequently used for text selection, etc.

Other than that, nominating for tracking into Firefox 5 as this goes along with the existing/landed work already on mozilla-aurora.
(In reply to comment #3)
> I think we want to be really, really careful here to ensure that we don't end
> up making it *harder* to double click elsewhere, which is frequently used for
> text selection, etc.

This code is completely isolated. It doesn't affect clicking anywhere except in the tab strip.
Unless UI team feels strongly about having this, we would not halt the cut over to beta for this.  If the UI team feels strong we can assess options, including backout.  The patch is also not yet reviewed so the risk assessment is not complete.
Oh, I see -- the flag I want to see flipped is the approval flag. Sorry, I misunderstood the new tracking mechanism.
Attachment #525277 - Flags: review?(gavin.sharp)
Comment on attachment 525277 [details] [diff] [review]
simplified patch

>-          setTimeout(function() {
>-            tabContainer._blockDblClick = false;
>-          }, 0);
>-          tabContainer.removeEventListener("click", enableDblClick, false);
>+          tabContainer._blockDblClick = false;
>+          tabContainer.removeEventListener("click", enableDblClick, true);
>         }
>-        tabContainer.addEventListener("click", enableDblClick, false);
>+        tabContainer.addEventListener("click", enableDblClick, true);

Why is it okay to reset _blockDblClick synchronously? The dblclick event is dispatched immediately after the click event.
(In reply to comment #7)
> Why is it okay to reset _blockDblClick synchronously? The dblclick event is
> dispatched immediately after the click event.

It is okay, because that branch is only reached the _second_ time that enableDblClick is run.

---

Example 1:

1. User clicks on a tab close button. The following code runs:
tabContainer.addEventListener("click", enableDblClick, true);

2. User clicks again quickly at the same location, but it's now on a blank part of the tab bar. Since it's a double-click, the following code runs:
Click event is dispatched, so enableDblClick simply does |clickedOnce = true;| then it returns.
Double-click event is dispatched, but _blockDblClick is true, so nothing happens.

3. The next time the user clicks on the tab-bar:
enableDblClick runs first, since its useCapture is true.
clickedOnce is true, so _blockDblClick is immediately set to false.
If the click was also a double-click, that's okay, since _blockDblClick is false again, as it should be.

---

Example 2:

1. User clicks on a tab close button. Code that runs:
tabContainer.addEventListener("click", enableDblClick, true);

2. User clicks again quickly at the same location, but it's now on another tab's close button. Since it's a double-click, the following code runs:
Click event is dispatched, and enableDblClick runs first:
_ignoredClick is set to true,
clickedOnce is set to true, and it returns.
The tab close button's click event handler runs:
event.detail > 1 but _ignoredClick is already true, so the tab is closed, as it should be.

3. Same as step 3 above.

---

The key is for the useCapture parameter of addEventListener to be true. If useCapture is false, enableDblClick will run immediately after the click in step 1, which isn't helpful.
(In reply to comment #8)
> Example 2:
> 
> 1. User clicks on a tab close button. Code that runs:
> tabContainer.addEventListener("click", enableDblClick, true);
> 
> 2. User clicks again quickly at the same location, but it's now on another
> tab's close button. Since it's a double-click, the following code runs:
> Click event is dispatched, and enableDblClick runs first:
> _ignoredClick is set to true,
> clickedOnce is set to true, and it returns.
> The tab close button's click event handler runs:
> event.detail > 1 but _ignoredClick is already true, so the tab is closed, as
> it should be.

The idea was that a double click shouldn't trigger two actions, e.g. close two tabs... see bug 409215 comment 4 for instance.
Comment on attachment 525277 [details] [diff] [review]
simplified patch

(In reply to comment #9)
> The idea was that a double click shouldn't trigger two actions, e.g. close
> two tabs... see bug 409215 comment 4 for instance.

This idea is, in this case, opposed to being responsive to user actions and having consistent, intuitive UI.

The case of not opening a new tab on the double click is different from closing a second tab that has already spent ~250ms expanding/sliding over such its close button is under the cursor. In the latter case, the user has sufficient time and visual feedback to see that the UI has changed into a state in which the second click will perform another action.
Attachment #525277 - Flags: ui-review?(limi)
If you think 250 ms are sufficient time to respond to feedback, then maybe you'd just never want a 250 ms pause to lead to a double click. Motor skills differ, so others may have a different preferences. The double click speed actually is variable and sometimes configurable (e.g. on Windows).
(In reply to comment #11)
> If you think 250 ms are sufficient time to respond to feedback, then maybe
> you'd just never want a 250 ms pause to lead to a double click. Motor skills
> differ, so others may have a different preferences. The double click speed
> actually is variable and sometimes configurable (e.g. on Windows).

If we think that 250ms is not sufficient time to respond to feedback, then we should not make the UI animate like this within that time interval, but that is a separate question.

More pertinently, if we have UI that animates, it is reasonable to a user that when her/she performs an action acting upon the state of the UI after the animation, the action will do something that reflects the current state of the UI.
Sure, the current UI doesn't cater for different needs (except that we do have the browser.tabs.animate hidden pref), but two wrongs don't make a right...
(In reply to comment #13)
> Sure, the current UI doesn't cater for different needs (except that we do
> have the browser.tabs.animate hidden pref), but two wrongs don't make a
> right...

I don't think it's two wrongs at all. Double-clicking resulting in two actions performed is expected behavior. If you double-click on a window close button when there are two windows exactly on top of each other, both windows will close. If you double-click on a back button, the page will navigate back in history twice. Once the state of the UI has changed, the action performed should change too.

Error prevention like we do to prevent opening a new tab should only occur in very specific cases when the state of the UI is unclear (e.g. the region of the tab strip becomes a blank region) and consequences of user error are unintuitive (e.g. a tab is opened when trying to close a tab).
(In reply to comment #14)
> I don't think it's two wrongs at all. Double-clicking resulting in two
> actions performed is expected behavior.

This is missing the point. Novices (who likely don't use tabs extensively but can still end up with a few tabs every now and then) don't always know where to perform a single click and where to perform a double click, and will likely double-click just in case when they're in doubt.
(In reply to comment #15)
> Novices don't always know
> where to perform a single click and where to perform a double click, and
> will likely double-click just in case when they're in doubt.

Where in the browser or in the OS even does a close button require a double click? What is the basis that a novice would expect a close button to require a double click?

Even if a novice performs a double click slow enough for the next tab to slide over, the user will likely notice that the action was performed upon the first click, so only one click was required, and that the second click was on the next close button, but nothing happened, making Firefox seem unresponsive.

On the other hand, a click on a close button and then a quick second click at the second screen coordinates but on a resulting blank region is really working around an implementation level problem: the OS and browser read it as a double click on the blank region, but, to the user, only one click was on the blank region, so it doesn't make sense that it was a double click.
(In reply to comment #16)
> Where in the browser or in the OS even does a close button require a double
> click? What is the basis that a novice would expect a close button to
> require a double click?

I don't think they have a uniform concept of a close button but rather a squishy perception of random handles on the screen triggering various actions.

I'm hypothesizing here, since I'm not such a user, but I've actually seen people double-click where a single click would suffice.

> Even if a novice performs a double click slow enough for the next tab to
> slide over, the user will likely notice that the action was performed upon
> the first click, so only one click was required, and that the second click
> was on the next close button, but nothing happened, making Firefox seem
> unresponsive.

This kind of reflection might occur when novices advance, but in my experience that's actually not guaranteed to happen.
(In reply to comment #17)
> I don't think they have a uniform concept of a close button but rather a
> squishy perception of random handles on the screen triggering various
> actions.
> 
> I'm hypothesizing here, since I'm not such a user, but I've actually seen
> people double-click where a single click would suffice.

Considering that handles can already be perceived to be random due to possible inconsistency within the OS and that we can only hypothesize about users, let's talk about principles ( http://uxmag.com/strategy/quantifying-usability ):

Is there a UX-consistency argument here? Yes. When clicking quickly twice on other buttons in the browser, it is treated as two clicks.

Is there a UX-efficiency argument here? Yes. A user should not have to wait until an invisible, seemingly arbitrary time threshold passes to be able to close another tab when the close button is already under the cursor.

Is there a UX-userfeedback argument here? Yes. The button is visually under the cursor, implying that the UI is ready to receive another click.

Is there a UX-error-prevention argument here? Yes. Allowing the double click to close two tabs leaves room for novice errors, but this argument is easily trumped by the arguments based upon other principles.
(In reply to comment #18)
> Considering that handles can already be perceived to be random due to
> possible inconsistency within the OS and that we can only hypothesize about
> users, let's talk about principles (
> http://uxmag.com/strategy/quantifying-usability ):
>
> Is there a UX-consistency argument here? Yes. When clicking quickly twice on
> other buttons in the browser, it is treated as two clicks.

For some click targets is, for some it isn't. Consistency works both ways.

It's worth noting that a tab closing unintentionally (as opposed to going back two pages instead of one) can effectively mean dataloss when these people don't know that they can undo it.

> Is there a UX-efficiency argument here? Yes. A user should not have to wait
> until an invisible, seemingly arbitrary time threshold passes to be able to
> close another tab when the close button is already under the cursor.

Doesn't apply to users who ponder for a few seconds before attempting to execute another action.

> Is there a UX-userfeedback argument here? Yes. The button is visually under
> the cursor, implying that the UI is ready to receive another click.

It implies that if you react fast enough and actually want to close two tabs, yes.

> Is there a UX-error-prevention argument here? Yes. Allowing the double click
> to close two tabs leaves room for novice errors, but this argument is easily
> trumped by the arguments based upon other principles.

They don't easily trump each other when they apply to different types of users. Obviously I'm not concerned about preventing this error for you and me, and I'm equally not concerned about my mom and my grandma complaining about a lack of efficiency -- they'll never even consider closing two tabs with a double click.
I'm not sure I fully understand the debate here, but I'm inclined to agree with Dao (at least I think I'm agreeing with Dao!) that the behaviour should be:

 - user clicks on the tab close button, ONE tab closes
 - user double clicks on the tab close button, ONE tab closes

Once the next close button target is underneath the mouse cursor and the double-click timeout has elapsed, the next click should close the next tab, IMO. This is the safest, least destructive option (as Dao mentions, novice users tend to double click where they ought not to - it happens) and if it annoys users, I'm sure we'll hear about it pretty quickly.
How about:

- We land this change on the UX branch and live with it for a while
- See if we can get numbers on how many people double click the close button on tabs via Test Pilot

I agree with both sides here, really (I know, not helpful ;) — I do experience my clicks to close go missing sometimes, but I also know that people double click everything because computers are unpredictable like that, and the easiest way is to double click everything.
FWIW, I would expect most power users to tune the double-click delay well under 250ms (I don't trigger a double-click when clicking at a 4 clicks per second rate ; if I speed up enough to trigger one, the close button isn't under the mouse in time for the second click).

Also, I generally prefer to use CTRL+W when closing multiple tabs.

This bug might still be a improvement (for occasional browsing on a family/shared computer or some such ; i.e. one where the double-click delay isn't shortened), but may not be crucial for most power users ...
(In reply to comment #21)
> How about:
> 
> - We land this change on the UX branch and live with it for a while

Pushed to UX branch:
https://hg.mozilla.org/projects/ux/rev/b00542095ae6

> - See if we can get numbers on how many people double click the close button
> on tabs via Test Pilot

More specifically, we'd want to find out how many people click the close button and then click again at the same location within ~200 milliseconds (before the next close button slides over). I'll talk to Jinghua about it.
Comment on attachment 525277 [details] [diff] [review]
simplified patch

We've been testing this on the UX branch for a month now, and it seems to work great.
Attachment #525277 - Flags: ui-review?(limi) → ui-review+
> We've been testing this on the UX branch for a month now, and it seems to
> work great.

I don't see how this can be a response to the concerns raised, as these concerns weren't about you and me in the first place...
Whiteboard: [Snappy]
Comment on attachment 525277 [details] [diff] [review]
simplified patch

This seems to contradict the first paragraph of the comment at the beginning of tabbrowser-close-tab-button's click handler, which suggests that double clicks only reach tab close buttons after click-to-select shows the tab close button. We should fix that comment, at the very least.

Seems like it would be simpler if the target.className == 'tab-close-button' check was in the tab-close-button event handler, rather than in this temporary listener. Or if that's not possible for some reason, you should at the very least add a comment that the "_ignoredClick = true" you're adding here is actually meant to prevent the click from being ignored (by pretending that we already ignored it once), since that's hard to grasp at first glance.

This behavior seems to be heavily dependent on the double-click threshold vs. tab close animation timing - I couldn't close two tabs with double click on my linux machine even with this patch applied.

All of this logic is very confusing, so I think we need to simplify as much as possible. I'm not sure bug 343628 is bad enough to justify having this convoluted logic - who really double clicks tab close buttons? We definitely to want to ensure bug 352021 remains fixed, and it's easy enough to keep bug 378344's fix.
Attachment #525277 - Flags: review?(dao) → review-
Frank: This bug is a Snappy priority. Can you please talk with Gavin to get any questions you have answered so we can continue with this bug?
Whiteboard: [Snappy] → [Snappy:P2]
I'm going to be very busy with other projects for the remainder of this week, so I'm unassigning myself for now, in case someone was looking to jump on it. I've read through Gavin's comments and will try to address them once I have time to work on this again.

I'm still just as interested in getting this fixed; it's simply a matter of available time.
Assignee: fryn → nobody
Status: ASSIGNED → NEW
Blocks: 771444
No longer blocks: 771444
Assignee: nobody → fyan
Status: NEW → ASSIGNED
Comment on attachment 525277 [details] [diff] [review]
simplified patch

Review of attachment 525277 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #27)
> All of this logic is very confusing, so I think we need to simplify as much
> as possible.

I didn't create the complicated logic. I'm actually simplifying it with this patch, including removing a setTimeout, so I don't think it makes sense to reject a patch when it's actually helping to remove complexity.

> I'm not sure bug 343628 is bad enough to justify having this
> convoluted logic - who really double clicks tab close buttons?

The user is not trying to trigger a double click event. The user is trying to close two different tabs. The problem is that the OS mechanism for deciding whether an event is a double click assumes that the UI isn't moving around during that threshold, but that's a Windows 95-era assumption from a time of few animations.

> We definitely
> to want to ensure bug 352021 remains fixed,

This patch does that.

> and it's easy enough to keep bug
> 378344's fix.

This patch does that.

If the complexity from bug 343628's patch is bad, then file a followup to get rid of more of that complexity, or back that patch out completely. It shouldn't block this patch, which takes a step in the right direction.
Attachment #525277 - Flags: review- → review?
Attachment #525277 - Flags: review? → review?(gavin.sharp)
(In reply to Frank Yan (:fryn) from comment #30)
> I didn't create the complicated logic.

I wasn't suggesting that it was your fault! Sometimes it's better to avoid "piling on" additional complication and revisit things; other times revisiting things is too much work and a short term band-aid is merited. Reasonable people can disagree about which particular case we're in, and the best way forward can change over time for various reasons.

> The user is not trying to trigger a double click event. The user is trying
> to close two different tabs.

I see no mention of that particular scenario in bug 343628, but maybe you're right that that was the original intent.

> If the complexity from bug 343628's patch is bad, then file a followup to
> get rid of more of that complexity, or back that patch out completely. It
> shouldn't block this patch, which takes a step in the right direction.

The overall goal is to have simple/maintainable code that gets us the behavior that we want - let's look at the big picture rather than focusing on the bugzilla/patch mechanics of how we do it. It may be that tackling the larger issue has a poor cost/benefit ratio compared to landing your patch as-is, but that's not the impression that I got when I last looked at this. I will look again.
Oh... People, could anybody fix this up at last?

My notebook's touchpad driver sets a double-click timeout at high value every time when Windows starts up. So I'm too tired of waiting about one second to close every subsequent tab. Anybody can reproduce my feelings by adjusting a double-click speed to "slow" in Mouse properties dialog and trying to serf or to develop some web-sites... (:
Yuck. This code is a confusing mess. I've been poking though it (and looking at historic bugs), and it's just not sinking in. Even the big comment block isn't really helping. Which all makes me wonder if the risk of breaking something is worth it what seems like a small tweak.

Can you explain again what this is actually changing and breaking?

I'll note that, from earlier in the bug, users who double-click everything (out of habit or inexperience or whatever) is absolutely a thing, so I'll agree with Dao and beltzner's 2011 (!) concerns about that -- comment 20 is spot on. I can't really tell if that's relevant to this patch, though.
(In reply to Justin Dolske [:Dolske] from comment #33)
> Can you explain again what this is actually changing and breaking?

All the patch does is make it so the following always works:
1. You click the close button of a tab. Its closing animation begins.
2. The tab closing animation completes, resulting in the close button of the next tab being right under the cursor as intended.
3. You click the close button of that next tab. That tab's closing animation begins. Voila!

Currently, this doesn't always work, because the OS's double-click threshold is usually longer than 250ms, so the OS reads the second click as a double-click, and we block that click from closing the second tab.
Try it: open a few tabs, close a tab in the middle, and then try to close the next tab right after it finishes sliding over. Nothing happens, and Firefox looks broken.

This patch is super simple, does not regress anything else, and already has ui-review+.
I recently bought a new laptop and started having the issue with having to double click to close consecutive tabs and as the firefox updates came together, I was wondering what was happening, because I didn't have this issue in my previous pc. The double-click speed of my mouse was set to 4 out of 11. I changed it to 9 and now I don't have to click twice. I can close one tab after another fast with a single click each time.
I know that it may not be a solution for everyone, but I mention it because it may be for some people.
(In reply to Frank Yan (:fryn) from comment #34)
> Currently, this doesn't always work, because the OS's double-click threshold
> is usually longer than 250ms, so the OS reads the second click as a
> double-click, and we block that click from closing the second tab.

Shouldn't our answer for people who are annoyed by this to lower their OS double-click threshold? I.e. make the people with the more "advanced" use case (quickly closing multiple tabs) have to adjust their OS, rather than optimizing our UI to effectively bypass an OS setting (and potentially annoying extra-double-clickers users performing a much more fundamental task)?
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #36)
> Shouldn't our answer for people who are annoyed by this to lower their OS
> double-click threshold? I.e. make the people with the more "advanced" use
> case (quickly closing multiple tabs) have to adjust their OS, rather than
> optimizing our UI to effectively bypass an OS setting (and potentially
> annoying extra-double-clickers users performing a much more fundamental
> task)?

No, we should not consider quickly closing tabs an "advanced" use case. I surmise that one of the reasons people needlessly double-click things, if they do at all, is that they are impatient and have gotten used to their computer not responding to their explicit input. We shouldn't make this worse by not responding to their clicks. Firefox users should be able to trust that when they click something, the UI will respond in a predictable manner intuitively comprehensible from the visual state of the browser.

Secondly, the concern about users trying to double-click close button due to OS conventions is questionable. Neither Windows nor OS X has close buttons that must be triggered by double-click. Neither Windows nor OS X block the second click for items that only require a single click, e.g. double-clicking binary checkboxes returns the checkbox to its original state, and double-clicking buttons triggers their command twice.

The primary reason that I care about this issue is that I think the principles that we apply here are generalizable. The solution to users accidentally clicking things is not to make Firefox less responsive and requiring delays for every action, making Firefox a frustrating product with lots of friction. Rather, we should make the UI responsive, simple to understand, and predictable -- trustworthy, if you will -- so users stop erratically clicking things out of confusion or impatience, and we support undo with discoverable UI whenever possible.
(In reply to Frank Yan (:fryn) from comment #37)
> No, we should not consider quickly closing tabs an "advanced" use case.

I knew that word might be misinterpreted - it's certainly more "advanced" than simply closing a tab, and that was my point.

> I surmise that one of the reasons people needlessly double-click things, if
> they do at all, is that they are impatient and have gotten used to their
> computer not responding to their explicit input.

No, I think they do it because some things require double clicks (e.g. opening a file on your desktop) and some things don't, and they don't care to distinguish between them. Anecdotal evidence suggests this is a pretty common problem - e.g. my mother double clicks links on web pages.

Letting the OS decide what a double click is (as basically all other apps do) and choosing to make double clicks not trigger tab closes seems like a reasonable state of affairs to me. Optimizing for users who a) try to quickly close tabs by clicking and b) don't change their OS double-click threshold (for whatever reason) just doesn't seem like the right tradeoff.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #38)
> Optimizing for users who a) try to
> quickly close tabs by clicking and b) don't change their OS double-click
> threshold (for whatever reason) just doesn't seem like the right tradeoff.

Just for me. I have a touch-pad driver that moves an OS double click threshold to high values every OS start-up. Unfortunately it isn't something from the open source software camp, so I can't change it's behavior.
Comment on attachment 525277 [details] [diff] [review]
simplified patch

Review of attachment 525277 [details] [diff] [review]:
-----------------------------------------------------------------

Trying to close tabs here is one of the most visible sources of jank in the browser. When we have a button in our UI that responds to hover and active states, and we allow the user to click on it, we should respond to the user's click. If you want to close three tabs in a row, the user literally has to sit and wait for Firefox. This is annoying and it gets in the way of the user.

I agree with Frank that this patch simplifies this code.
Attachment #525277 - Flags: review?(gavin.sharp) → review+
Just had an IRC conversation with Frank and Jared. The relevant points were:
- there's no such protection against accidental clicks in other similar contexts, like the OS window close button
- this bug causes clicks to not be responded to somewhat unpredictably, while the bug I am concerned this might cause (users accidentally closing two tabs on double click) is correctable once users figure out what's going on
- other browsers don't seem to do this

Given that, I withdraw my objections, let's land this and see how it works.
https://hg.mozilla.org/integration/mozilla-inbound/rev/9c669c34363c
Summary: Make clicking quickly at the same location to close multiple tabs actually work → Remove unnecessary delay when clicking tab close buttons sequentially
Target Milestone: --- → Firefox 23
Uhm. You asked me to look at this, and after discussing it I said I'd like to think over a few things, but then this lands without even a courtesy ping? Why the sudden rush?

I'm also kinda concerned about the path the arguments in this bug have taken. It seems like there's some talking past each other, argument by assertion, and I might even go so far to say that a bit of it verges on hyperbole. It's not a disaster, but I wouldn't hold this bug up as an model of how to hold a UX discussion. :(

Anyway. The specific issue I wanted to look into is about those users who might be doubleclicking the tab close buttons (and now unexpectedly closing an extra tab), and what (if anything) we should do about that. It's been raised a few times here, but I don't think it's been adequately addressed. It's clearly a thing some users do -- I know I've heard of it repeatedly, and a quick Google turns up various discussions on the topic. As a tiny selection:

http://discuss.joelonsoftware.com/default.asp?joel.3.698762.25
http://blogs.msdn.com/b/oldnewthing/archive/2004/10/15/242761.aspx
http://nosmirkale.com/rant/doubleclick.html
http://lockergnome.net/questions/95311/do-you-hate-how-your-parents-always-double-click-on-things

And, amusingly, http://doubleclickeverything.tumblr.com/ :-)

Of particular interest, from http://baymard.com/blog/people-still-double-click-online:

====
During our most recent research study we once again found that a surprisingly  large number (more than 50%) of the people aged 40+ still double-click on links and form buttons online.

This gives us a tiny glimpse into the vast proportions of novice users out there. These people are not stupid, they just have better things to do than learn that they have to treat links and buttons online differently from the documents and folders on their desktop.
====

Finally! A little actual data! I don't have Firefox demographic data handy, but 50% of older users is a lot of people. Of course, how well that maps to users doubleclicking on _close buttons_ is hard to answer without more research, but I suspect it'll correlate well. And so we should damn well take a moment to think about the potential impact.


So, what to do here. Well, I'll note a few things:

* Of the historical bugfixes I see here, both bug 343628 (which first added this code) and bug 378344 were avoiding quirky -- but not harmful -- behavior due to doubleclicks. Only bug 352021 was about a harmful result, and even then it noted "I think we were pretty "meh" on this case in general, but might as well fix it".

* None of these bugs (esp. 352021) were user-generated or refer to user-reported problems. 

* I'm not aware of any other parts of the browser where we do this kind of doubleclick suppression, nor is it something we routinely consider when evaluating UI, nor is it something that I've seen in any kind of "checklist for good design" for applications in general. [And other discussion indicates that neither do other browers or tabbed apps do this.]

* Bug 409215 is eerily similar to this bug, except about the single tab-close button on the tab-strip, instead of the per-tab close button. It has a handful of end-user comments, as does this one.

* We don't really know how many always-doubleclickers are going to be closing multiple tabs, because we've essentially always accidentally guarded against that.

* It _seems_ like most of the Googleable discussion about this issue is at least a few years old, and predates the single-tap UI that iOS/Android teaches. I'd be comfortable assuming that the number of always-doubleclickers is declining.

* I think it's also plausible to posit that most of these users are novice users, that novice users tend to use fewer (if any) tabs, and thus to some degree this issue is self-limiting.


It's a bit of a leap-of-faith, but in short, I think this is one of those cases where we've got both some clear upside and some unclear but potentially significant downside. And in a user segment for which we have limited visibility or feedback, at that. That's a hard risk tradeoff to predict. But since it's a bit handwavy either way, I think it's reasonable to, as gavin put it, "land this and see how it works".
(In reply to Justin Dolske [:Dolske] from comment #43)
> [And other discussion indicates that neither do other browers or tabbed apps do this.]

May be I haven't understood your idea in all aspects. But I've tested Google Chrome and have found that tabs in it closes every time I click on the tab close button without any dependencies from OS double click threshold.

The correct behavior of browser's UI for my mind is not to close second tab while animation is in progress, but to close the second tab when tab's close button is under cursor and is clicked.

> I've seen in any kind of "checklist for good design" for applications in general.
And I have. (: There is a good example in any OS, I think:
1. Open two windows.
2. Place these windows one above another so close buttons have to be one above another too.
3. Make double click on the topmost window's close button.
4. Result: OS closes two windows with out any check for double click threshold.
https://hg.mozilla.org/mozilla-central/rev/9c669c34363c
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
> I'm not aware of any other parts of the browser where we do this kind of
> doubleclick suppression, nor is it something we routinely consider when
> evaluating UI

I just want to point out that processing the second click as a double click when the two clicks occur in different controls (as a result of the first control disappearing or sliding away) sounds like the wrong thing to do. Suppressing it completely or processing it as a single click both make more sense.

Standard controls on Windows don't suppress the second click in this scenario; they process it as a single click. If you rig a button to be hidden on click, and then try to double-click it, the second click will NOT register as a double-click, and it WILL register as a single click on the control below the button. It's not suppressed, nor seen as a double-click.

Whether Firefox should play along with that is a separate question, of course, but I think one needs compelling reasons to override this sensible convention. Glad to see this fix landed.
(In reply to Roman from comment #46)
> I just want to point out that processing the second click as a double click
> when the two clicks occur in different controls (as a result of the first
> control disappearing or sliding away) sounds like the wrong thing to do.
> Suppressing it completely or processing it as a single click both make more
> sense.

Maybe the terminology is confusing, but "suppressing it completely" is pretty much what the code used to do, by ignoring the event in that case (and "processing as a single click" is what the code does after this patch). I suppose it might be interesting to investigate having the lower level DOM event code actually only fire double click events if the target was the same for both clicks, but that's a scarier sounding change from a web compat point of view (this patch only touched the front-end applicaiton logic for dealing with the events).
As a user I've been frustrated with this for the better part of a year. I got fed up with it and did some research and found this, glad to see a fix is rolling out. By no means am I a developer, but as a power user this was very frustrating. Limiting the rate of tab closing and making it unresponsive was insanely annoying.
(In reply to urshilikai from comment #48)
> As a user I've been frustrated with this for the better part of a year. I
> got fed up with it and did some research and found this, glad to see a fix
> is rolling out. By no means am I a developer, but as a power user this was
> very frustrating. Limiting the rate of tab closing and making it
> unresponsive was insanely annoying.
As in bug 869402, currently a consistent rate of clicking X produces an inconsistent success rate in closing tabs!
(In reply to jidanni from comment #51)
> As in bug 869402, currently a consistent rate of clicking X produces an
> inconsistent success rate in closing tabs!

This bug has been fixed in Nightly builds of Firefox. You can run Nightly if you want to get access to the fix before it comes to Aurora, Beta, or Release builds. http://nightly.mozilla.org/
22.0a2 (2013-05-03) still has MY bug.
So you will have to be more specific,
as I am on Debian.
(In reply to jidanni from comment #53)
> 22.0a2 (2013-05-03) still has MY bug.
> So you will have to be more specific,
> as I am on Debian.

The "Target Milestone" for this bug is Firefox 23, which means that Firefox 23 is the first version where it is fixed. Since you are running 22.0a2, that would mean that you are running Firefox Aurora. If you download Firefox Nightly, then you will have the fix (http://nightly.mozilla.org).
OK I will wait for it to get to Debain instead.
$ apt-cache policy iceweasel 
iceweasel:
  Installed: 22.0~a2+20130503004014-1
  Candidate: 22.0~a2+20130503004014-1
  Version table:
 *** 22.0~a2+20130503004014-1 0
        990 http://mozilla.debian.net/ experimental/iceweasel-aurora i386 Packages
        100 /var/lib/dpkg/status
     20.0-1 0
        990 http://ftp.br.debian.org/debian/ experimental/main i386 Packages
     17.0.5esr-1 0
        500 http://ftp.br.debian.org/debian/ unstable/main i386 Packages
Something must have broken this on UX, since it works fine on Nightly but no more on the UX branch.
Depends on: 880277
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: