Closed Bug 192729 Opened 21 years ago Closed 21 years ago

Keyboard focus non-functional after error when opening link in new tab

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: taralx, Assigned: aaronlev)

References

(Blocks 1 open bug)

Details

(Keywords: access, testcase, Whiteboard: [Hixie-P0][Hixie-2.0])

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030209
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030209

If I open a link in a new tab and get an error box, the page is still gray and
the keyboard shortcuts don't work (ctrl-L doesn't go to URL bar, ctrl-W doesn't
close the tab). I have to click in the window to get keyboard to work again.

Bug 90919 may be related.

Reproducible: Always

Steps to Reproduce:
Steps to reproduce:

1. Select URL bar
2. Type garbage (e.g. aldkjflsf)
3. Hit ctrl-enter.
4. Hit stop.
5. Type ctrl-w.

Expected result:

New tab closes.

Actual result:

Nothing happens!
-> Brian Ryner, focus/events
Assignee: aaronl → bryner
Blocks: focusnav
Can nobody confirm this?
Happens to me often with the 1.3 release under Linux.  Usually as soon as I
hit Ctrl-T to try and open a new tab; no tab is opened and the browser completely
stops responding to any keyboard action at all.
I have the same (non-)behavior here.

Steps to reproduce:
1. Load an URL that takes some seconds by STRG-clicking on a link.
2. Type CTRL-TAB to switch tab.

expected: switch tab
actual: no reaction. You have to click in the (still gray) tab first or wait
until the page has been loaded.
Have patch
Assignee: bryner → aaronl
Attachment #127153 - Flags: review?(bryner)
*** Bug 211850 has been marked as a duplicate of this bug. ***
*** Bug 112337 has been marked as a duplicate of this bug. ***
Just transferring keywords from bug 112337.
Keywords: access, sec508, testcase
Attachment #127153 - Flags: superreview?(roc+moz)
Comment on attachment 127153 [details] [diff] [review]
New blank tabs have no frame -- key press events need to be retargeted to parent

This looks OK but I wonder what side effects there could be. Hopefully only
good ones since we just avoid throwing away some events.
Attachment #127153 - Flags: superreview?(roc+moz) → superreview+
FWIW, this may be related to bug 145315.  This happens to me all the time,
and I've been adding observations and notes in that bug's trail.
Whiteboard: [Hixie-P0][Hixie-2.0]
Would it be better to make the new tab load about:blank if there's an error?
If this would allow at least to close the tab again, I'm ok with it. I only
don't want to close the window :)
Is this a duplicate of Bug #110718 or not?
Bryner, I dont think that would be better. It would only be fixing a specific 
case. We shouldn't just throw away keyboard events. They should always at least 
go up to the parent doc if the current once can't handle them. Very similar to 
the fix we used for key event lost during the zomobie stage, which worked well. 
I find it likely that this will fix other keydead problems.
Also happens with 1.4:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030704

The procedure in bug 145315 is still needed to regain keyboard awareness.
> Would it be better to make the new tab load about:blank if there's an error?
Most importantly against this idea is that it wouldn't help while the tab is
still trying to load, before the error. We're keydead then as well.
*** Bug 212760 has been marked as a duplicate of this bug. ***
Hm, that seems odd to me.  I thought new docshells synchronously loaded
about:blank, which should enable events to be handled immediately...

But you're right, this is better than throwing the event away.

Attachment #127153 - Flags: review?(bryner) → review+
checked in
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Wouldn't this be good to get for 1.4.x as well? (Not setting flags, but I think
it would...)
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: