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

VERIFIED FIXED in Firefox 3.1b2

Status

()

defect
VERIFIED FIXED
11 years ago
11 years ago

People

(Reporter: dholbert, Unassigned)

Tracking

({regression})

Trunk
Firefox 3.1b2
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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.)
Summary: When held, Ctrl-Tab keeps cycling *after Tab is released* → When held, Ctrl-Tab keeps cycling for a while *after Tab is released*
Tested using a debug mozilla-central build from today, btw.
The mentioned behavior also happens on OS X.
OS: Linux → All
Hardware: PC → All
(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.
Summary: When held, Ctrl-Tab keeps cycling for a while *after Tab is released* → When held, Ctrl-Tab keeps cycling for a while *after Tab is released*, locking up OS
Severity: normal → major
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.
Severity: major → normal
(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.
Severity: normal → major
Severity: major → normal
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().
Depends on: 77992
Depends on: 116088
Depends on: 456088
This should be fixed by bug 456088.
Target Milestone: --- → Firefox 3.1b2
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.