Open
Bug 352349
Opened 18 years ago
Updated 1 year ago
Arrow Keys cause lose of focus in List within Add-ons
Categories
(Firefox :: Disability Access, defect)
Tracking
()
NEW
People
(Reporter: deangelo, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: access, regression)
Attachments
(2 files, 2 obsolete files)
3.00 KB,
patch
|
asaf
:
review-
|
Details | Diff | Splinter Review |
422 bytes,
application/vnd.mozilla.xul+xml
|
Details |
Env: Bon Echo nightly build 20060912.
Problem: When arrowing within the add-ons dialog focus jumps to get extension button.
1. Open Add-Ons dialog (Alt+T, then press A)
2. If not focused on the list of add-ons, press Tab until the list has focus.
We had 2 add-ons in the list: DOM Inspector 1.8.1b2 and Talkback 2.0b2
3. Arrow down to the last item in the list (Talkback).
4. Tab to the "Enable" button.
5. Press Down Arrow twice. (First Down Arrow moves focus to the "Uninstall" button, the second Down Arrow moves focus to the "Get Extensions" button at the bottom of the dialog.)
Expected Result:
The focus should not jump down to the "Get Extensions" button by pressing Down Arrow. The Arrow keys should move only within the add-on list. You should have to press Tab to get out of the list and get down to the buttons at the bottom of the dialog.
Reporter | ||
Updated•18 years ago
|
Flags: blocking-firefox2?
Comment 1•18 years ago
|
||
Would not hold the release for this since there is a workaround - but if we can get a patch in time we'd gladly consider.
Flags: blocking-firefox2? → blocking-firefox2-
Comment 2•18 years ago
|
||
Per IRC discussion with aaronlev, if a button is contained within a richlistitem, we want the richlistitem to handle all arrow keys. This means you can no longer use the arrow keys to move between multiple buttons that are all contained within a single richlistitem (you can still use tab / shift-tab though).
Rejected proposal: make richlistitem use phase="capturing" for handling key events and never let child controls see the arrow keys. Rejected because there might be other controls (like the new slider control) where we need it to handle at least left and right arrow keys. We should let the nearest control get first crack at the key events, and if there are other controls that do their own processing of arrow keys, we should deal with conflicts on a per-control basis.
Updated•18 years ago
|
Flags: blocking-firefox2- → blocking-firefox2?
Comment 3•18 years ago
|
||
Comment on attachment 238211 [details] [diff] [review]
if button is inside a richlistitem, let richlistitem handle arrow keys
Only changing the phase should break nothing. Of course, you'll probably want to do event.stopPropagation() in the richlistitem handler in cases in which this makes sense.
button.xml should know nothing about richlistitem.
Attachment #238211 -
Flags: review?(bugs.mano) → review-
Updated•18 years ago
|
Flags: blocking-firefox2? → blocking-firefox2-
Updated•18 years ago
|
Target Milestone: --- → Firefox 3 alpha1
Comment 4•18 years ago
|
||
Implemented phase=capturing at mano's suggestion.
Attachment #238211 -
Attachment is obsolete: true
Attachment #239219 -
Flags: review?
Updated•18 years ago
|
Attachment #239219 -
Flags: review? → review?(mano)
Comment 5•18 years ago
|
||
Attachment #239219 -
Attachment is obsolete: true
Attachment #239226 -
Flags: review?(mano)
Attachment #239219 -
Flags: review?(mano)
Comment 6•18 years ago
|
||
Comment on attachment 239226 [details] [diff] [review]
styling changes
OK, r=mano.
Attachment #239226 -
Flags: review?(mano) → review+
Comment 7•18 years ago
|
||
Comment on attachment 239226 [details] [diff] [review]
styling changes
Actually, no. As expected, this breaks cases in which arrows should work, e.g. xul <scale> element insdie a richlistitem.
What I think you should do is:
1) Merge the keypress handlers into one handler, and switch-case on the keycode.
2) Actually handle the event only if the richlistitem itself or a xul button inside it is the event target (and only stop the event propagation in these cases).
Note that this should not break a11y, it's always possible to shift-tab from the <scale> element back to the richlistitem itself.
Attachment #239226 -
Flags: review+ → review-
Comment 8•18 years ago
|
||
Updated•18 years ago
|
Comment 9•17 years ago
|
||
Still valid for Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0
Updated•11 years ago
|
OS: Windows XP → Windows 7
Hardware: x86 → x86_64
Target Milestone: Firefox 3 alpha1 → ---
Version: 2.0 Branch → 31 Branch
Comment 10•11 years ago
|
||
Pressing the down arrow when the focus is on "Remove" of the last Extension, then the focus goes to the tab. Pressing down again, then Firefox jumps to the next tab.
Comment 11•6 years ago
|
||
I can not reproduce this issue with the latest Firefox extension manager (which is itself getting a re-write to be HTML rather than XUL) Is this still a bug?
Comment 12•3 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months.
:asa, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee: pilgrim → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(asa)
Updated•2 years ago
|
Severity: normal → S3
Comment 13•2 years ago
|
||
based on comment from Asa 4 years ago -- is this still a bug? If not, let's close it!
Comment 14•1 year ago
|
||
Clear a needinfo that is pending on an inactive user.
Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE
.
For more information, please visit BugBot documentation.
Flags: needinfo?(asa)
You need to log in
before you can comment on or make changes to this bug.
Description
•