Pressing Ctrl+Tab quickly fails to switch tabs




11 years ago
10 years ago


(Reporter: jruderman, Unassigned)


Bug Flags:
wanted1.9.1 +

Firefox Tracking Flags

(Not tracked)




11 years ago
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.
Flags: blocking-firefox3.1?
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
I've now done some 1.9.0-branch tests on Windows and Linux (both using

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.
Assignee: nobody → joshmoz
Component: Tabbed Browser → Widget: Cocoa
Flags: blocking-firefox3.1?
Product: Firefox → Core
QA Contact: tabbed.browser → cocoa
Version: Trunk → unspecified
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.
Assignee: joshmoz → smichaud
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Priority: -- → P3
No longer blocks: 395980

Comment 10

11 years ago
> 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.
Flags: wanted1.9.0.x?
(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).
Assignee: smichaud → joshmoz

Comment 15

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


11 years ago
Flags: wanted1.9.1? → wanted1.9.1+


10 years ago
Assignee: joshmoz → nobody
You need to log in before you can comment on or make changes to this bug.