Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1a1pre) Gecko/2008071609 Minefield/3.1a1pre Steps to reproduce: 1. Make sure you have at least two (!) tabs open. 2. Press Ctrl+Tab quickly (release Ctrl quickly after pressing Tab). Result: Nothing happens. Expected: Switch to the most recently selected tab. (Preferably without flashing the tab-switching panel on the screen.) I'm using a debug build of Firefox, which might make this bug easier to reproduce.

I can't reproduce this. I tested in FF3 and FF3.0.1 on OS X 10.5.4. First I tested with 4 tabs open. Then I added ~30 tabs (by going to Latest Headlines in the Bookmarks Toolbar and choosing "open all in tabs"). In repeated testing I didn't see the problem even once. Later I'll test on OS X 10.4.11, and with a debug build.

I've now been able to reproduce this on OS X 10.4.11, both in FF 3.0.1 and in a debug build (1.9.0-branch). Interestingly, in my tests the problem only happens with tabs that are fully loaded (not ones that haven't yet finished loading). In other words, ctrl-tab only (occasionally) "gets stuck" in tabs that are fully loaded. And once a tab "gets stuck", it's much more likely that it will stay "stuck" (that subsequent ctrl-tabs will keep failing to switch the next tab, if you press ctrl-tab quickly enough).

This isn't a 1.9.0 branch bug. I haven't seen it on trunk either, though.

I've seen it on the 1.9.0 branch (comment #2), though only on OS X 10.4.11. I haven't ever seen it on OS X 10.5.4. I suspect that's the crucial factor. (I'm now doing a mozilla-central debug build on 10.5.4, and will test it later.)

I see a _different_ problem on trunk, on both OS X 10.5.4 and 10.4.11: Open four tabs. Notice that ctrl-tab only alternates between two of them -- not between all four as it should. The speed with which you keep pressing ctrl-tab doesn't seem to matter. Which two you alternate between seems to depend on which tab you start out on (say by selecting it with the mouse). In both cases I tested with today's mozilla-central nightly (2008-07-18-06-mozilla-central).

I've now done some 1.9.0-branch tests on Windows and Linux (both using FF3). On both OSes, though FF3 sometimes falls behind in processing ctrl-tabs, it always eventually catches up. In other words, if you do a whole bunch of ctrl-tabs in a row rapidly, FF3 can sometimes pause for a few seconds, and then (slowly) switch tabs until it's "consumed" all the ctrl-tabs you pressed. The delays are worse if you have many (> 30) tabs open. I see the same lag on OS X 10.5.4 (where I've not seen the problem Jesse reported in comment #0) -- if I test on a slow enough machine (the old MacBook Pro I also used to test on 10.4.11). I don't see the lag on OS X 10.4.11 (where I _have_ seen the problem Jesse reported). Somehow the "excess" ctrl-tab events are eaten on 10.4.11 (possibly by the OS), but not on the other OSes.

(Following up comment #5) I see the same "problem" on Windows and Linux (testing with today's mozilla-central nightly). It now appears to be not a bug but a feature (i.e. the little window that opens whenever you have multiple tabs and press ctrl-tab). So how do you turn off this "feature" (if that's possible), so as to be able to test for what Jesse originally reported?

If this is fixable, it will probably be in Cocoa widgets code.

Since (as best we can currently tell) this only happens on OS X 10.4.X, I rate it a P3. I'll increase the priority if things turn out otherwise.

> So how do you turn off this "feature" (if that's possible), so as to > be able to test for what Jesse originally reported? I reported this bug after the new feature landed. It's a bug that affects the new feature, so you shouldn't need to turn off the feature in order to test the bug.

Well, I found a bug myself, which is (basically) identical to what you reported in comment #0. And reproducing that _does_ require turning off this new feature, as best I can tell. Maybe what you've reported is actually different from what I saw (and from what you appear to report in comment #0). Please provide more detail.

Or at least answer me this: Does the problem you saw happen on both OS X 10.5.4 and 10.4.11, or only on 10.4.11? Does it also happen on Windows and/or Linux?

Not clear that this bug actually affects Firefox 3 or just trunk builds since the new ctrl-tab feature landed. Please renom if you can reproduce in a Gran Paradiso nightly.

(In reply to comment #13) I can still reproduce the bug I reported in comment #2 with today's Granparadiso nightly (2008-08-18-04-mozilla1.9.0). But that's (apparently) not the bug Jesse originally reported (which, by the way, I still can't reproduce). "My" bug is arguably not very important, in any case (happens only on OS X 10.4.11, hard to reproduce, minor consequences).

I still see the bug I reported in comment 0. I'm using a trunk debug build on Mac OS X 10.4.x.