Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

VERIFIED FIXED in mozilla13

Status

()

Core
Disability Access APIs
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: Jamie, Assigned: surkov)

Tracking

(Blocks: 1 bug, {regression})

Trunk
mozilla13
x86_64
Windows 7
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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
(Assignee)

Updated

6 years ago
Blocks: 368895

Comment 1

6 years ago
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
(Reporter)

Comment 2

6 years ago
Using a braille display is exactly how i found the bug. :)
(Assignee)

Comment 3

6 years ago
Created attachment 594105 [details] [diff] [review]
patch

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.
(Assignee)

Comment 5

6 years ago
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 7

6 years ago
Comment on attachment 594105 [details] [diff] [review]
patch

r=me for the tests.
Attachment #594105 - Flags: review?(marco.zehe) → review+
(Assignee)

Comment 8

6 years ago
inbound https://hg.mozilla.org/integration/mozilla-inbound/rev/0dbe46d2c255

Comment 9

6 years ago
https://hg.mozilla.org/mozilla-central/rev/0dbe46d2c255
Status: ASSIGNED → RESOLVED
Last Resolved: 6 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.