Closed Bug 397219 Opened 13 years ago Closed 13 years ago

Tab not moving focus relative to caret when caret inside label

Categories

(Core :: DOM: Selection, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: jdiggs, Assigned: aaronlev)

References

(Blocks 1 open bug)

Details

(Keywords: access, Whiteboard: orca:high)

Attachments

(2 files)

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!
Severity: normal → major
Whiteboard: orca:high
Assignee: aaronleventhal → nobody
Component: Disability Access APIs → Layout
OS: Linux → All
QA Contact: accessibility-apis → layout
Hardware: PC → All
Summary: setCaretOffset() on a label should remove focus from other items → Tab not moving focus relative to caret when caret inside label
Assignee: nobody → aaronleventhal
Status: NEW → ASSIGNED
Component: Layout → Selection
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?
Flags: blocking1.9?
I did not mean to request blocking, sorry for the spam.
Flags: blocking1.9?
Attached file 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
This is actually an old regression from bug 244179, fixed 8/2/2004
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.
Attachment #286314 - Flags: review?(mats.palmgren)
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/
Attachment #286314 - Flags: review?(mats.palmgren) → review+
Attachment #286314 - Flags: approval1.9?
Attachment #286314 - Flags: approval1.9? → superreview?(neil)
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/?
Attachment #286314 - Flags: superreview?(neil) → superreview+
Attachment #286314 - Flags: approval1.9?
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Note: this was temporarily backed out to see if that fixes the orange on tinderbox, but it hasn't.
You need to log in before you can comment on or make changes to this bug.