Closed
Bug 248566
Opened 20 years ago
Closed 20 years ago
<input type="file" /> gets focused by any alt+navigation key
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: TailsTheKitsune, Assigned: neil)
References
Details
Attachments
(1 file, 1 obsolete file)
716 bytes,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040623 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040623 If a file input exists on a page, hitting alt+left (shortcut for hitting the back button) gives focus to the file input instead of going to the previous page. User is left with no choice but to manually click the back button. Reproducible: Always Steps to Reproduce: 1. Create a text input 2. Press alt+left in the page Actual Results: text input steals focus (as if it were a text input). Expected Results: The browser should jump to the previous page.
Updated•20 years ago
|
Assignee: general → aaronleventhal
Component: Browser-General → Keyboard: Navigation
QA Contact: general
Comment 1•20 years ago
|
||
I suspect this was caused by Neo's checkin for bug 206376
Assignee: aaronleventhal → neo.liu
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•20 years ago
|
||
This also happens for alt+home, alt+right, alt+insert, alt+delete, alt+f2 ... Perhaps whenever charCode is 0?
Severity: normal → major
Summary: <input type="file" /> on page breaks alt+left "back" navigation. → <input type="file" /> gets focused by any alt+navigation key
Comment 3•20 years ago
|
||
if i understand correctly, accesskey only support single character. and for special key like "F1", we can't specify it as a accesskey in html. here is the patch.
Updated•20 years ago
|
Attachment #151993 -
Flags: review?(aaronleventhal)
Assignee | ||
Comment 4•20 years ago
|
||
Any <input accesskey=""> will trigger this bug...
Comment 5•20 years ago
|
||
Comment on attachment 151993 [details] [diff] [review] patch How about |if (!accessKey.IsEmpty())| instead? That might be more optimal. Anyway, you would need spaces around the >. Other than that looks right.
Attachment #151993 -
Flags: review?(aaronleventhal) → review+
Comment 6•20 years ago
|
||
Neo, we need to fix it so SetAccessKey(emptystring) does nothing
Assignee | ||
Comment 7•20 years ago
|
||
Assignee: neo.liu → neil.parkwaycc.co.uk
Attachment #151993 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Assignee | ||
Updated•20 years ago
|
Attachment #152023 -
Flags: superreview?(roc)
Attachment #152023 -
Flags: review?(roc)
Comment on attachment 152023 [details] [diff] [review] Stop form frames registering empty access keys You had me confused for a minute. The summary should be "Stop form frames registering *empty* access keys" :-)
Attachment #152023 -
Flags: superreview?(roc)
Attachment #152023 -
Flags: superreview+
Attachment #152023 -
Flags: review?(roc)
Attachment #152023 -
Flags: review+
Assignee | ||
Comment 9•20 years ago
|
||
Comment on attachment 152023 [details] [diff] [review] Stop form frames registering empty access keys D'oh!
Attachment #152023 -
Attachment description: Stop form frames registering non-empty access keys → Stop form frames registering empty access keys
Assignee | ||
Comment 10•20 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 11•20 years ago
|
||
*** Bug 250009 has been marked as a duplicate of this bug. ***
Updated•5 years ago
|
Component: Keyboard: Navigation → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•