Closed
Bug 192729
Opened 22 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)
Core
DOM: UI Events & Focus Handling
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)
899 bytes,
patch
|
bryner
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
62 bytes,
text/html
|
Details |
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!
Assignee | ||
Comment 2•21 years ago
|
||
-> Brian Ryner, focus/events
Assignee: aaronl → bryner
Blocks: focusnav
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.
Comment 5•21 years ago
|
||
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.
Assignee | ||
Comment 7•21 years ago
|
||
Assignee | ||
Updated•21 years ago
|
Attachment #127153 -
Flags: review?(bryner)
Assignee | ||
Comment 8•21 years ago
|
||
Assignee | ||
Comment 9•21 years ago
|
||
*** Bug 211850 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 10•21 years ago
|
||
*** Bug 112337 has been marked as a duplicate of this bug. ***
Comment 11•21 years ago
|
||
Just transferring keywords from bug 112337.
Assignee | ||
Updated•21 years ago
|
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+
Comment 13•21 years ago
|
||
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.
Updated•21 years ago
|
Whiteboard: [Hixie-P0][Hixie-2.0]
Comment 14•21 years ago
|
||
Would it be better to make the new tab load about:blank if there's an error?
Comment 15•21 years ago
|
||
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 :)
Comment 16•21 years ago
|
||
Is this a duplicate of Bug #110718 or not?
Assignee | ||
Comment 17•21 years ago
|
||
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.
Comment 18•21 years ago
|
||
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.
Assignee | ||
Comment 19•21 years ago
|
||
> 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.
Comment 20•21 years ago
|
||
*** Bug 212760 has been marked as a duplicate of this bug. ***
Comment 21•21 years ago
|
||
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.
Updated•21 years ago
|
Attachment #127153 -
Flags: review?(bryner) → review+
Assignee | ||
Comment 22•21 years ago
|
||
checked in
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 23•21 years ago
|
||
Wouldn't this be good to get for 1.4.x as well? (Not setting flags, but I think it would...)
Updated•5 years ago
|
Component: Keyboard: Navigation → User events and focus handling
Comment 24•5 years ago
|
||
Keywords: sec508
You need to log in
before you can comment on or make changes to this bug.
Description
•