Closed Bug 723833 Opened 9 years ago Closed 9 years ago

IAccessibleText::setCaretOffset on location or search bar causes focus to jump

Categories

(Core :: Disability Access APIs, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla13

People

(Reporter: Jamie, Assigned: surkov)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file)

Str:
1. Press control+l to move to the location bar.
2. Type some text.
3. Get the accessible for the location bar.
4. Call IAccessibleText::setCaretOffset(0) on the location bar accessible.
Expected: The caret should move to the start of the text.
Actual: The focus moves, either to the top level frame or to the tab bar.
Note: Any caret offset (except the current caret offset) will cause this behaviour.

5. Press control+k to move to the search bar.
6. Type some text.
7. Get the accessible for the search bar.
8. Call IAccessibleText::setCaretOffset(0) on the search bar accessible.
Expected: The caret should move to the start of the text.
Actual: The focus moves, either to the top level frame or to the tab bar.
Note: Any caret offset (except the current caret offset) will cause this behaviour.

Tested in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120201 Firefox/13.0a1
Blocks: texta11y
This is confirmed and can also be seen by using a braille display and trying to route the caret to any of the characters in the location bar or search field. Focus jumps to the tabs at the top of the window. This is a regression, since it used to work that one could route the caret via the routing buttons on a braille display.
Keywords: regression
Using a braille display is exactly how i found the bug. :)
Attached patch patchSplinter Review
not sure I like solution but nothing better comes into my mind
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #594105 - Flags: review?(trev.saunders)
(In reply to alexander :surkov from comment #3)
> Created attachment 594105 [details] [diff] [review]
> patch
> 
> not sure I like solution but nothing better comes into my mind

well, I'm not sure I like what we started with, particularly I dislike that we seem to just focus the next thing after we've moved the focus to do what we need to.

SOme questions I have are:
*what is supposed to happen if you set the  caret in something that isn't focused? should it become focused or should we fail?
* for that matter what about  the other callers? it seems more reasonable to want to copy / delete / paste text in something not focused than to set the caret.
* is it bad if we save the current focus move it to the thing we want to work on then restore it when we are done?  I'd think idealy selecting text and focus would be orthoginal, ubt maybe that's not possible and restoring the state after the task has been completed is the best we can do.
It seems caretOffset is expected to focus that's what we did basically. Due to some reason we don't focus when window is unfocused and probably we shouldn't change that.

It might be that we change focus for selection changes because of implementation details (we ask an editor to complete an action) but it sounds nobody cares.
Comment on attachment 594105 [details] [diff] [review]
patch

I think I'm fine with this change, but I don't have time to look at the tests in any detail until wensday so r=me on the C++ and r? marco on the tests.
Attachment #594105 - Flags: review?(trev.saunders)
Attachment #594105 - Flags: review?(marco.zehe)
Attachment #594105 - Flags: review+
Comment on attachment 594105 [details] [diff] [review]
patch

r=me for the tests.
Attachment #594105 - Flags: review?(marco.zehe) → review+
https://hg.mozilla.org/mozilla-central/rev/0dbe46d2c255
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120209 Firefox/13.0a1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.