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.)

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

The mentioned behavior also happens on OS X.

(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.

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)

(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.

(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.

(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.

(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.

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()).

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

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)

(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().

This should be fixed by bug 456088.

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