450138 - When held, Ctrl-Tab keeps cycling for a while *after Tab is released*, locking up OS

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Daniel Holbert [:dholbert]]

Steps to reproduce:
1. Open three tabs with different contents.
2. Hold Ctrl-Tab for 5 seconds
3. Release Tab (and Ctrl, if you want -- doesn't matter)

EXPECTED RESULTS:  Tab-switching should stop pretty much immediately

ACTUAL RESULTS:    Tab-switcher stays up & keeps cycling for another ~5-6 seconds, making Firefox completely unusable during that time.

Note: The following switchers show expected behavior, stopping in a fraction of a second after tab is released no matter how long it was held:
 - Firefox 3.0.x's old-style Ctrl-Tab switching
 - Gnome's default alt-tab switching

(Adding 'regression' keyword since Firefox 3.0.x's switcher didn't have this problem.)

Comment 1

[Daniel Holbert [:dholbert]]

Tested using a debug mozilla-central build from today, btw.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The mentioned behavior also happens on OS X.

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to comment #0)
> ACTUAL RESULTS:    Tab-switcher stays up & keeps cycling for another ~5-6
> seconds, making Firefox completely unusable during that time.

Actually, this makes *my whole desktop* completely unusable during that time.  If I click other windows or try any standard keyboard commands (e.g. Alt-F1 for Gnome menu) while Ctrl-Tab is finishing up, I get no response.

Comment 4

[Daniel Holbert [:dholbert]]

If I try the steps from comment 0 in today's nightly with the Ctrl-Tab extension (because the fix for bug 445573 doesn't seem to be in that nightly), then the Ctrl-Tab "cooldown time" is greatly reduced, probably due to optimization.

However, even in the optimized build, there still is a noticeable amount (1/2 - 1 sec) of cooldown time after 5 seconds of holding Ctrl-Tab.  And the cooldown is longer if I hold Ctrl-Tab for longer.  (e.g. there's ~2 sec of cooldown after 15 seconds of holding Ctrl-Tab)

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to comment #4)
> If I try the steps from comment 0 in today's nightly with the Ctrl-Tab
> extension (because the fix for bug 445573 doesn't seem to be in that nightly),

Sorry -- I wasn't very clear about that part.  What I meant was this: bug 445573 isn't fixed in today's nightly, which means that you can't test this bug here in today's nightly.  However, bug 445573 *is* fixed in the Ctrl-Tab firefox extension ( https://addons.mozilla.org/en-US/firefox/addons/versions/5244 ).  So if you install that extension, then you *can* test this bug.

Comment 6

[Dão Gottwald [:dao]]

(In reply to comment #4)
> However, even in the optimized build, there still is a noticeable amount (1/2 -
> 1 sec) of cooldown time after 5 seconds of holding Ctrl-Tab.  And the cooldown
> is longer if I hold Ctrl-Tab for longer.  (e.g. there's ~2 sec of cooldown
> after 15 seconds of holding Ctrl-Tab)

No big deal, imho -- there's no practical use of doing that.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to comment #6)
> No big deal, imho -- there's no practical use of doing that.

Well, maybe it's not too severe, then.  But still...
 - "No practical use" doesn't mean our users won't run into this bug and be annoyed / turned off by it. (Holding ctrl-tab to watch the tabs whiz by is fun, if not practical. :))
 - This bug indicates something that's inherently broken -- we shouldn't be "accumulating cooldown time" like this.
 - This bug is particularly annoying in debug builds, where (as comment 0 states) there's a pretty severe cooldown penalty. (about one second of cooldown per second of tab-switching.)  That makes this something of an issue for dogfooding / testing.

Comment 8

[Dão Gottwald [:dao]]

(In reply to comment #7)
>  - This bug indicates something that's inherently broken

It just means that our performance isn't good enough to keep up with how fast the keypress events occur.

Comment 9

[Dão Gottwald [:dao]]

I thought I could use event.timeStamp to skip events when falling behind. But on Windows the reference point is when the computer started up, so I don't think there's a way to compare event.timeStamp to the current time (e.g. new Date().getTime()).

Comment 10

[Dão Gottwald [:dao]]

... and on Linux event.timeStamp is always 0, I think.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

Are you sure event.timeStamp doesn't work on Linux? It seems to be implemented, so worth filing a bug if so.

(this might also explain some strange behavior in Fennec (http://mxr.mozilla.org/mobile-browser/source/chrome/content/deckbrowser.xml#965)

Comment 12

[Dão Gottwald [:dao]]

(In reply to comment #11)
> Are you sure event.timeStamp doesn't work on Linux? It seems to be implemented,
> so worth filing a bug if so.

I get a number now, but I'm not sure what it is. document.createEvent("Events").timeStamp seems to have a different dimension, and neither is comparable to Date.now().

Comment 13

[Dão Gottwald [:dao]]

This should be fixed by bug 456088.

Comment 14

[Marcia Knous [:marcia]]

verified fixed using  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081118 Minefield/3.1b2pre and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081118 Minefield/3.1b2pre