112337 - Blank tab (not about:blank) can lose focus completely, can't Ctrl-Tab out of empty tab, all keyboard shortcuts fail

Status: RESOLVED DUPLICATE of bug 192729

(SeaMonkey :: Tabbed Browser, defect)

Description

[ltskinol]

Linux: 2001112712

This is a pretty trivial bug, but annoying nonetheless.  Blank tabs get a
different focus than tabs with a page loaded in them.  The annoying thing
about this is that the focus for blank tabs is set up such that the
tab-switching keyboard shortcuts don't work.

Note: I have the pref "Load links in the background" checked.

To reproduce:

1. Open Mozilla.
2. Load a page containing a bad URL.
3. Right-click on the bad URL, and select "Open in new tab."  Wait for the
   bad URL to not load and dismiss the error dialog.  You now have a 
   foreground tab with a real page, and a background blank tab with no page
   loaded.
4. Ctrl+PgDn switches to the new blank tab, as expected.
5. Ctrl+PgUp doesn't switch back to the original page.
6. Click inside the page area of the blank tab.  Now Ctrl+PgUp works.

Expected: #5 should work without having to do #6.

This is annoying for us folks who use middle-mouse to open everything in
new tabs.  When we get a bad link, we can't keyboard past the blank tab.

Comment 1

[sairuh (rarely reading bugmail)]

this is because focus is in the urlbar --and iirc, when focus is there many
keyboard shortcuts don't work, like ctrl+pageUp/pageDown.

Comment 2

[ltskinol]

Don't think so.  If the focus was in the URL bar,

- Ctrl+W wouldn't work (it does).
- You could start typing a URL (you can't).

Another interesting thing: after switching to the blank
tab, Shift+Tab never moves the focus to the URL bar,
no matter how many times you hit it, implying that
the focus is somewhere weird.  Normal Tab (key) goes to
the URL bar the first time you hit it.

Comment 3

[sairuh (rarely reading bugmail)]

ah! i created a test case [which i'll attach since the url is internal to nscp]
with a bad link, and i now understand what you're seeing. it also happens on
winNT and mac 10.1.1.

bryner, should this go to you?

to test:
1. open http://hopey.mcom.com/tests/bad-link.html
2. bring up context menu for the link "http://foo.foo/" and select Open in New Tab.
3. dismiss the resulting alert dlg.
4. try use keyboard shortcuts, eg: ctrl+pageUp, ctrl+pageDown, accel+W...

results: the keyboard shortcuts won't work. in fact, in this state, focus
doesn't seem to be anywhere...noticed that the cursor isn't even in the urlbar
of the [new] blank tab.

if i click [tabbing doesn't work] in the blank tab's content area, i can use
accel+W to close and ctrl+pageUp to switch to the previous tab. but if i hit
ctrl+pageDown in the tab with real content [which does return me to the blank
tab], keyboard navigation in the new tab is dead again.

Comment 4

[sairuh (rarely reading bugmail)]

Attachment: download or click to this test page and follow the steps...

Comment 5

[Brian Ryner (not reading)]

-> jag

Comment 6

[jag (Peter Annema)]

-> future

Comment 7

[Jonas Jørgensen]

*** Bug 125589 has been marked as a duplicate of this bug. ***

Comment 8

[Alfonso Martinez]

*** Bug 160642 has been marked as a duplicate of this bug. ***

Comment 9

[Matt Brubeck (:mbrubeck)]

More information:

If I open a new tab or window and type "http://foo.foo/" in its URL bar, the
content area is initially blank white (my default background color) and remains
white after the URL fails to load.  Keyboards shortcuts work normally.

If I open a link to "http://foo.foo/" in a new tab to load in the background (as
in the test case) the content area is initially blank gray, and remains gray
after the error message.  The default white background is never painted. 
Keyboard shortcuts don't work.

This bug is extremely annoying for keyboard-only users...

Comment 10

[Matt Brubeck (:mbrubeck)]

More information:  I can't reproduce this in Mozilla 1.1 on Linux.

Comment 11

[Tom 7]

I can confirm this with every recent version of Mozilla on Windows XP. Very
annoying!

Comment 12

[Dominik Stadler]

Still seeing this with 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20021218

This is really annoying. Many, many links on webpages are not working nowadays
and everytime I open a link in a new tab and this page is not found, I have to
grab for the mouse and click on the tab with the mousewheel-button. No keyboard
shortcut seems to be able to close such tabs. Also ALT-F does not show the
File-Menu to reach "Close Tab" there.

It seems that the focus is on some hidden item, as it is neither in the page nor
in the location bar.

This behavior can also be seen when opening an url in a new tab in the
background via clicking with the mousewheel on a link.

Comment 13

[Gilles Durys]

*** Bug 189319 has been marked as a duplicate of this bug. ***

Comment 14

[Gilles Durys]

*** Bug 189703 has been marked as a duplicate of this bug. ***

Comment 15

[Sander]

*** Bug 192033 has been marked as a duplicate of this bug. ***

Comment 16

[Sander]

*** Bug 182794 has been marked as a duplicate of this bug. ***

Comment 17

[Sander]

*** Bug 165082 has been marked as a duplicate of this bug. ***

Comment 18

[Sander]

*** Bug 150289 has been marked as a duplicate of this bug. ***

Comment 19

[Sander]

*** Bug 165902 has been marked as a duplicate of this bug. ***

Comment 20

[Josh Birnbaum]

*** Bug 166367 has been marked as a duplicate of this bug. ***

Comment 21

[Nicu Buculei]

i'm using error pages instead of dialogs with the line
user_pref("browser.xul.error_pages.enabled", true); 
in prefs.js and this bug doesn't affect me at all.
when bug 28586 will be checked this bug will be automatically resolved

Comment 22

[Matt Brubeck (:mbrubeck)]

Re: bug 28586

Not quite.  That fixes the problem when when a page return an error right away,
but there are still bad accessibility and usability problems when pages time
out, or load correctly after a long delay.

Comment 23

[Aaron Green, MD]

One more consequence of this bug: if you have your home page set as BLANK PAGE,
when you start up Mozilla, you can't ALT-D and start entering a site. You have
to use the mouse to click in the window first.

Comment 24

[Alex Vincent [:WeirdAl]]

dmitry:  the blocking 1.3 flag is for drivers to determine if Mozilla 1.3 final
should be held for this bug to be fixed.  If you want drivers to evaluate this
bug as possibly blocking 1.3, set the flag to "?".  Only drivers should set a
flag to "+" or "-".

Per direction of dbaron, setting flag to "?".

Removing 0.9.8 keyword as that was released a long time ago.

Comment 25

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 26

[Josh Birnbaum]

*** Bug 194417 has been marked as a duplicate of this bug. ***

Comment 27

[Steve Simms]

*** Bug 195771 has been marked as a duplicate of this bug. ***

Comment 28

[Boris Zbarsky [:bzbarsky]]

*** Bug 198719 has been marked as a duplicate of this bug. ***

Comment 29

[Chris Casciano]

*** Bug 198741 has been marked as a duplicate of this bug. ***

Comment 30

[R.K.Aa.]

*** Bug 198959 has been marked as a duplicate of this bug. ***

Comment 31

[Alfonso Martinez]

*** Bug 201947 has been marked as a duplicate of this bug. ***

Comment 32

[Hermann Schwab]

bug 201947 claimed that gray tabs couldn´t be deleted by CTRL-W.
To create a gray tab, I loaded a URL which led to time-out, and then opened the
'try again' link in a new tab, which resulted in creating a gray tab.
At two tries I could delete that tab with Ctrl-W, but when I wanted to copy the
cryptic URL from the location bar, mozilla froze. It didn´t show frozen in
Windows Task Manager Window (Ctrl-Alt-Del), so I aborted Taskmanager, not Mozilla,
and Mozilla had focus again, Ctrl-W worked.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030412
chrome://global/content/netError.xhtml?e=netTimeout&u=http%3A//bugzilla.mozilla.org/buglist.cgi%3Fbug_status%3DUNCONFIRMED%26bug_status%3DNEW%26bug_status%3DASSIGNED%26bug_status%3DREOPENED%26bug_status%3DRESOLVED%26changedin%3D1%26chfield%3D%255BBug+creation%255D%26chfieldto%3DNow%26product%3DBrowser%26product%3DMailNews%26cmdtype%3Ddoit%26order%3DReuse+same+sort+as+last+time&d=The%20operation%20timed%20out%20when%20attempting%20to%20contact%20bugzilla.mozilla.org.

Comment 33

[resigned]

(comment I just added to bug202245, which is probably about to be marked a dupe
of this one)

"If it is the same bug, then the description/summary for Bug 112337 is really
really bad.

This seems to be broken with ALL keyboard shortcuts (at least those I could
think of to try), not just ctrl-tab (which I've never even used, so I couldn't
find that bug when searching for dupes and deciding whether or not to create a
new bug). If this is a dupe, the other bug should have its summary "improved".
Sigh, this is a recurring issue with bugzilla - so many dupes just because the
original bug-report has a poor / too narrowly-defined summary.

Also, note that in addition to all comments in Bug 112337, this happens when you
"open in a new tab" any download link.

But other than that, I agree that this is probably the same bug."

Comment 34

[Sander]

adam: Try including bugs with resolution duplicate in your searches, that way
you find all the bugs with more 'logical' summaries.
Still, expanding this summary.

Comment 35

[Sander]

*** Bug 202245 has been marked as a duplicate of this bug. ***

Comment 36

[Ferdinand]

*** Bug 205691 has been marked as a duplicate of this bug. ***

Comment 37

[Aaron Leventhal]

Bryner, any interest in taking this one?

I just realized this is a Section 508 bug. Triagers, can this be plussed? It
happens quite a bit when a page fails to load.

Comment 38

[Samir Gehani]

adt: nsbeta1-

Comment 39

[Jason M. Abels]

*** Bug 209041 has been marked as a duplicate of this bug. ***

Comment 40

[Aaron Leventhal]

 

*** This bug has been marked as a duplicate of 192729 ***

Comment 41

[Ed Sabol]

What the heck?! Bug 192729 is newer, has no priority keywords, has way fewer
comments, and it has fewer votes. This bug should be reopened and bug 192729
should be marked a duplicate of this bug.

Comment 42

[Pascal Chevrel:pascalc]

It's not logical but I believe aaron made this bug a duplicate because he has a
patch attached to bug 192729 that will solve the problem.

Comment 43

[Aaron Leventhal]

Yeah, but the other bug was where I put my patch. Didn't know about this one.

If you want to migrate the patch and testcase from the other one, and migrate
the flags go ahead.

Comment 44

[Ed Sabol]

> Yeah, but the other bug was where I put my patch. Didn't know about this one.

That's funny since I see that you've posted multiple comments to this very bug
over the past few months.

But since you have a patch that presumably fixes this long-standing problem, all
is forgiven. Patches trump everything.

> If you want to migrate the patch and testcase from the other one, and migrate
> the flags go ahead.

I tried. Unfortunately, I'm not a "sufficiently empowered user" to do such things.

Comment 45

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381