397219 - Tab not moving focus relative to caret when caret inside label

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect)

Description

[Joanmarie Diggs]

Steps to reproduce:

1. Navigate to https://bugzilla.mozilla.org/enter_bug.cgi?product=Core

2. Tab to a focusable object near the top of the page (e.g. the Reports link)

3. Launch Accerciser and locate a true label (e.g. the "blocking1.8.1.8" label).  Select this label within Accerciser.

4. In Accerciser's iPython Console, type the following:

  text = acc.queryText()
  text.setCaretOffset(3)

5. Alt Tab back to Minefield.  The caret should be within the label.  Arrow right or left to verify this.

6. Press Tab to move to the next focusable object

Expected results:  After step 5, focus would be removed from the location chosen in step 2.  After step 6, focus would move to the item that follows the label (e.g. the blocking1.8.1.8 combo box)

Actual results:  After step 5, focus is visually still at the location chosen in step 2.  After step 6, not surprisingly, focus moves to the next focusable object that follows your location from step 2.

I am requesting that this be included among the other "Firefox 3 Accessibility Commitments" (bug 396346).  Aaron, since I know you'll ask... :-)  I do not yet know if this is a regression or not.  My guess would be that it's something we just haven't noticed because so many forms fail to use proper labels. :-(  For those that do, however, the current behavior is confusing/disorienting.

Thanks!

Comment 1

[Aaron Leventhal]

It seems like the bug is really:
Setting in the caret inside a label doesn't remove focus from its previous position.

Is that right?

Comment 2

[Aaron Leventhal]

I did not mean to request blocking, sorry for the spam.

Comment 3

[Aaron Leventhal]

Attachment: Testcase

1. Load the testcase and turn on caret browsing (F7)
2. Tab to a checkbox and then move the caret with the arrow keys
3. Press tab or shift+tab. The next item focused should be relative to the caret, not the previously focused checkbox

Comment 4

[Aaron Leventhal]

This is actually an old regression from bug 244179, fixed 8/2/2004

Comment 5

[Aaron Leventhal]

Attachment: Remove fix from bug 244129. It is not necessary anymore. Testcase still works because focus will prefer to move relative to a focused control now, and only relative to the caret if the doc has focus

This doesn't regress anything because the change we made in bug 244179 is not necessary to fix that testcase. This is because when you click in the label, focus moves to the form control it points to, and the next tab/shift+tab uses the focused item (and tabindex from that if it exists) to decide where to go.

If you move out the form control with the caret, onto text, the focus is removed from the control and to the document. With this patch, that again happens even if the text is in a label.

Comment 6

[Mats Palmgren (inactive)]

Comment on attachment 286314 [details] [diff] [review]
Remove fix from bug 244129. It is not necessary anymore. Testcase still works because focus will prefer to move relative to a focused control now, and only relative to the caret if the doc has focus

Looks good, r=mats

Perhaps update the comment below the change, s/Next check/Check/

Comment 7

[[e-mail]]

Comment on attachment 286314 [details] [diff] [review]
Remove fix from bug 244129. It is not necessary anymore. Testcase still works because focus will prefer to move relative to a focused control now, and only relative to the caret if the doc has focus

Bugzilla makes a very good testcase, simply move the caret up and down between Keywords and Whiteboard.

Perhaps s/Next/First/?

Comment 8

[Aaron Leventhal]

Note: this was temporarily backed out to see if that fixes the orange on tinderbox, but it hasn't.