Closed
Bug 213922
Opened 21 years ago
Closed 21 years ago
Pages rendered via a HREF TARGET= tag lose keyboard navigation focus
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: rhiggins, Unassigned)
References
()
Details
(Keywords: regression)
Attachments
(2 files)
199 bytes,
text/html
|
Details | |
1.36 KB,
patch
|
bryner
:
review+
bugs
:
superreview+
brendan
:
approval1.7b+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
A page rendered in a new browser window via a TARGET= tag in an HREF loses the
ability to use keyboard navigation. Page-Up/Page-Down/Arrow keys, etc....
The focus appears to go to the address/location bar instead of the browser
window contents.
Reproducible: Always
Steps to Reproduce:
1. Load this page http://www.bigscreen.com/Shop/index.php
2. Click the Charlies Angles pic which spawns a new window
3. Try to scroll up and down the page using the keyboard arrow keys
Actual Results:
No ability to scroll page using the keyboard. (mouse wheel works though)
Expected Results:
Focus should be on the document instead of the address bar. It didn't used to
be this way in previous versions to the best of my knowledge.
Browser theme doesn't affect this problem. (modern and classic behaviour is
the same)
Comment 1•21 years ago
|
||
didn't we fix this once, jag?
Reporter | ||
Comment 2•21 years ago
|
||
Click the link, try to scroll
Comment 3•21 years ago
|
||
Ugh. We fail this testcase with Mozilla 1.7 Alpha and Firefox 0.8
Assignee: general → events
Status: UNCONFIRMED → NEW
Component: Browser-General → Event Handling
Ever confirmed: true
Flags: blocking1.7b+
Keywords: regression
QA Contact: general → ian
Comment 4•21 years ago
|
||
Looks like this is seamonkey only now, I can't reproduce in FireFox, but I can
in SeaMonkey.
Comment 5•21 years ago
|
||
This fixes the problem in this case, but it might break other cases. Still
investigating if more is needed...
Comment 6•21 years ago
|
||
Comment on attachment 143524 [details] [diff] [review]
This fixes the focus problem in this case.
It might be worth just adding a brief mention to the comment describing the
case you mentioned about window.open("");
sr=ben@mozilla.org
Attachment #143524 -
Flags: superreview+
Updated•21 years ago
|
Attachment #143524 -
Flags: review?(bryner)
Comment 7•21 years ago
|
||
Comment on attachment 143524 [details] [diff] [review]
This fixes the focus problem in this case.
After thinking more about this, and testing more, and talking to people about
this fix, it's looking like this is the way to go. I've added the comment Ben
requested, now requesting approval to land this in 1.7b (once I have r=).
Attachment #143524 -
Flags: approval1.7b?
Updated•21 years ago
|
Attachment #143524 -
Flags: review?(bryner) → review+
Comment 8•21 years ago
|
||
Comment on attachment 143524 [details] [diff] [review]
This fixes the focus problem in this case.
a=brendan@mozilla.org for 1.7b.
/be
Attachment #143524 -
Flags: approval1.7b? → approval1.7b+
Comment 9•21 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 10•21 years ago
|
||
*** Bug 206960 has been marked as a duplicate of this bug. ***
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•