Closed
Bug 723833
Opened 12 years ago
Closed 12 years ago
IAccessibleText::setCaretOffset on location or search bar causes focus to jump
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
VERIFIED
FIXED
mozilla13
People
(Reporter: Jamie, Assigned: surkov)
References
(Blocks 1 open bug)
Details
(Keywords: regression)
Attachments
(1 file)
9.29 KB,
patch
|
tbsaunde
:
review+
MarcoZ
:
review+
|
Details | Diff | Splinter Review |
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
Comment 1•12 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•12 years ago
|
||
Using a braille display is exactly how i found the bug. :)
Assignee | ||
Comment 3•12 years ago
|
||
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)
Comment 4•12 years ago
|
||
(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•12 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 6•12 years ago
|
||
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•12 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•12 years ago
|
||
inbound https://hg.mozilla.org/integration/mozilla-inbound/rev/0dbe46d2c255
Comment 9•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/0dbe46d2c255
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
Comment 10•12 years ago
|
||
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.
Description
•