Closed Bug 112337 Opened 23 years ago Closed 21 years ago

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

Categories

(SeaMonkey :: Tabbed Browser, defect)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 192729
Milestone:
Future

People

(Reporter: ltskinol, Assigned: jag+mozilla)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: access, helpwanted, testcase)

Attachments

(1 file)

download or click to this test page and follow the steps...
333 bytes, text/html
Details 
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.
this is because focus is in the urlbar --and iirc, when focus is there many
keyboard shortcuts don't work, like ctrl+pageUp/pageDown.
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.

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.
Assignee: hyatt → bryner
URL: http://hopey.mcom.com/tests/bad-link....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: access, mozilla0.9.8, testcase
OS: Linux → All
Hardware: PC → All
-> jag
Assignee: bryner → jaggernaut
-> future
Target Milestone: --- → Future
Summary: Blank tab gets different focus than non-blank tab → Blank tab (not about:blank) can lose focus completely
*** Bug 125589 has been marked as a duplicate of this bug. ***
Blocks: 140346
Whiteboard: [Hixie-P0]
Whiteboard: [Hixie-P0] → [Hixie-P0][Hixie-2.0]
Blocks: focusnav
No longer blocks: 140346
No longer blocks: focusnav
*** Bug 160642 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → pmac
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...
More information:  I can't reproduce this in Mozilla 1.1 on Linux.
I can confirm this with every recent version of Mozilla on Windows XP. Very
annoying!
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.
*** Bug 189319 has been marked as a duplicate of this bug. ***
Summary: Blank tab (not about:blank) can lose focus completely → Blank tab (not about:blank) can lose focus completely, can't Ctrl-Tab out of empty tab
*** Bug 189703 has been marked as a duplicate of this bug. ***
*** Bug 192033 has been marked as a duplicate of this bug. ***
*** Bug 182794 has been marked as a duplicate of this bug. ***
*** Bug 165082 has been marked as a duplicate of this bug. ***
*** Bug 150289 has been marked as a duplicate of this bug. ***
*** Bug 165902 has been marked as a duplicate of this bug. ***
*** Bug 166367 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
QA Contact: pmac → sairuh
Flags: blocking1.3+
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
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.
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.
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.
Flags: blocking1.3+ → blocking1.3?
Keywords: mozilla0.9.8
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
*** Bug 194417 has been marked as a duplicate of this bug. ***
Flags: blocking1.3? → blocking1.3-
*** Bug 195771 has been marked as a duplicate of this bug. ***
Flags: blocking1.4a?
Flags: blocking1.4a? → blocking1.4a-
*** Bug 198719 has been marked as a duplicate of this bug. ***
*** Bug 198741 has been marked as a duplicate of this bug. ***
*** Bug 198959 has been marked as a duplicate of this bug. ***
*** Bug 201947 has been marked as a duplicate of this bug. ***
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 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."
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.
Summary: Blank tab (not about:blank) can lose focus completely, can't Ctrl-Tab out of empty tab → Blank tab (not about:blank) can lose focus completely, can't Ctrl-Tab out of empty tab, all keyboard shortcuts fail
*** Bug 202245 has been marked as a duplicate of this bug. ***
*** Bug 205691 has been marked as a duplicate of this bug. ***
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.
Blocks: focusnav
Keywords: nsbeta1- → nsbeta1, sec508
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
*** Bug 209041 has been marked as a duplicate of this bug. ***
 

*** This bug has been marked as a duplicate of 192729 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
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.
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.
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.
> 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.
Whiteboard: [Hixie-P0][Hixie-2.0]
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: