Wayne DeAngelo Reporter
	Description • 18 years ago

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.

	Mike Schroepfer
	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.

	Mark Pilgrim (inactive)
	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.

	Asaf Romano (gone)
	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.

	Mark Pilgrim (inactive)
	Comment 4 • 18 years ago

Implemented phase=capturing at mano's suggestion.

	Asaf Romano (gone)
	Comment 6 • 18 years ago

Comment on attachment 239226 [details] [diff] [review]
styling changes

OK, r=mano.

	Asaf Romano (gone)
	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.

	Marco Zehe (:MarcoZ)
	Comment 9 • 16 years ago

Still valid for Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0

	Tobias B. Besemer [:BesTo] (QA)
	Comment 10 • 10 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.