Open Bug 352349 Opened 18 years ago Updated 7 months ago

Arrow Keys cause lose of focus in List within Add-ons


(Firefox :: Disability Access, defect)

31 Branch
Windows 7




(Reporter: deangelo, Unassigned)


(Blocks 3 open bugs)


(Keywords: access, regression)


(2 files, 2 obsolete files)

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.
Flags: blocking-firefox2?
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-
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.
Assignee: nobody → pilgrim
Attachment #238211 - Flags: review?(bugs.mano)
Flags: blocking-firefox2- → blocking-firefox2?
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-
Flags: blocking-firefox2? → blocking-firefox2-
Target Milestone: --- → Firefox 3 alpha1
Implemented phase=capturing at mano's suggestion.
Attachment #238211 - Attachment is obsolete: true
Attachment #239219 - Flags: review?
Attachment #239219 - Flags: review? → review?(mano)
Attached patch styling changesSplinter Review
Attachment #239219 - Attachment is obsolete: true
Attachment #239226 - Flags: review?(mano)
Attachment #239219 - Flags: review?(mano)
Comment on attachment 239226 [details] [diff] [review]
styling changes

OK, r=mano.
Attachment #239226 - Flags: review?(mano) → review+
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-
Attached file testcase
Still valid for Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0
OS: Windows XP → Windows 7
Hardware: x86 → x86_64
Target Milestone: Firefox 3 alpha1 → ---
Version: 2.0 Branch → 31 Branch
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.

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?

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
Flags: needinfo?(asa)
Severity: normal → S3

based on comment from Asa 4 years ago -- is this still a bug? If not, let's close it!

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.