Closed Bug 227887 Opened 21 years ago Closed 20 years ago

Ctrl+Tab doesn't work in failed (gray, completely blank) tab

Categories

(Firefox :: Toolbars and Customization, defect, P2)

x86
All
defect

Tracking

()

VERIFIED FIXED
Firefox1.0beta

People

(Reporter: dalangalma, Assigned: bugzilla)

References

Details

(Keywords: fixed-aviary1.0, testcase)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

This might be related to Bug 210952 - If a tab in a tabset (from bookmarks)
fails to load a page (blahblah page not found) and you try to Ctrl+Tab through
all the tabs, the cycle will stop at that failed tab. You'll be tabbing along,
and suddenly - stopped. Not a very major bug, but it's there.

Reproducible: Always

Steps to Reproduce:
1. Make a bookmark folder that includes a site that fails to load for some
reason. (DNS trouble, whatever)
2. Load all the bookmars into tabs as a tabset.
3. Ctrl+Tab through the tabs. 

Actual Results:  
It'll stop cycling at the failed page.

Expected Results:  
Continued to cycle through tabs.
Dup of bug 112337 or bug 177030?  Fixed for zombie pages, but not for tabs that
haven't had any pages in them, in bug 110718.
Something strange: Ctrl+Tab doesn't work in failed tabs, but many keyboard
shortcuts (Ctrl+W, Ctrl+N) do work.
Summary: Ctrl +Tab stops cycling through tabs at failed page from tabset → Ctrl+Tab doesn't work in failed (gray, completely blank) tab
*** Bug 230907 has been marked as a duplicate of this bug. ***
I still see this bug in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a)
Gecko/20040128 Firebird/0.8.0+
so it's not a dup of any of the bugs I mentioned in comment 1.
Status: UNCONFIRMED → NEW
Ever confirmed: true
See also bug 232770, "Tab-switching shortcuts don't work when address bar has
focus (Ctrl+Tab, Ctrl+PgDn)".
*** Bug 216258 has been marked as a duplicate of this bug. ***
Jesse-
Why did an earlier bug get marked a dupe of this one instead of vice versa?
alan: because this bug is cross-referenced and has a slightly better summary.
Assignee: blake → hyatt
Component: General → Toolbars
QA Contact: bugzilla
This is not only a Windows XP problem.  I'm using Firefox 0.8 under Linux here
and I can reproduce it.

However, not only Ctrl+Tab, but *no* key works.  This is really bad, because it
makes keyboard navigation impossible and forces the user to use the mouse.

It furthermore is not necessary to use bookmarks -- every time that gray page
appears (I think it's when a server doesn't respond), the keyboard navigation
completely stops working, until mouse-clicking into the gray page or elsewhere.

I do not think that this is only a minor bug.  It really should be fixed, as it
is very annoying.
OS: Windows XP → All
Felix: sounds like you're hitting bug 223675, which is Linux-specific.  Ctrl+Tab
is broken for failed pages on all platforms, but other shortcuts like Ctrl+W are
only broken on Linux.
Another way to reproduce the problem (or is it another problem):

1. Open some page in a tab
2. Open another tab with the URL http://serber.chsc.dk/misc/ctrltab/
3. Notice that CTRL+TAB does not work, but only when that tab is active
4. Wait 30 seconds.
5. Notice that CTRL+TAB now works again.

http://serber.chsc.dk/misc/ctrltab/ is a regular HTML page, that includes a
stylesheet file. The stylesheet is actually a PHP file that sleeps for 30
seconds before outputting anything.

If you access http://serber.chsc.dk/misc/ctrltab/sleep.php?seconds=30 directly,
CTRL+TAB still works. In other words, if an include file is loading slowly,
CTRL+TAB gets disabled until the include file is loaded. This is the case with
both external stylesheets and Javascript includes.
Adding blocking1.0? - I experience this bug several times a day.

Very annoying if you open a lot of tabs in the background - when you cycle
through the tabs to get to the one that completes loading first, you may get
stuck at a tab that loads slowly.
Flags: blocking1.0?
Keywords: testcase
Flags: blocking1.0? → blocking1.0+
Assignee: hyatt → bugs
Severity: minor → normal
Priority: -- → P2
Target Milestone: --- → Firefox1.0beta
Assignee: bugs → sspitzer
Flags: blocking-aviary1.0RC1+
-> me
Assignee: sspitzer → firefox
Fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
WFM in a current branch build
Status: RESOLVED → VERIFIED
Keywords: fixed-aviary1.0
QA Contact: bugzilla → toolbars
You need to log in before you can comment on or make changes to this bug.