Closed
Bug 213922
Opened 20 years ago
Closed 20 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•20 years ago
|
||
didn't we fix this once, jag?
Reporter | ||
Comment 2•20 years ago
|
||
Click the link, try to scroll
Comment 3•20 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•20 years ago
|
||
Looks like this is seamonkey only now, I can't reproduce in FireFox, but I can in SeaMonkey.
Comment 5•20 years ago
|
||
This fixes the problem in this case, but it might break other cases. Still investigating if more is needed...
Comment 6•20 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•20 years ago
|
Attachment #143524 -
Flags: review?(bryner)
Comment 7•20 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•20 years ago
|
Attachment #143524 -
Flags: review?(bryner) → review+
Comment 8•20 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•20 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
![]() |
||
Comment 10•20 years ago
|
||
*** Bug 206960 has been marked as a duplicate of this bug. ***
Updated•5 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
•