Closed Bug 1170242 Opened 9 years ago Closed 7 years ago

Setting the caret via AtkText should scroll content into view


(Core :: Disability Access APIs, defect)

Not set



Tracking Status
firefox41 --- affected
firefox58 --- fixed


(Reporter: jdiggs, Assigned: samuel.thibault)


(Blocks 1 open bug)



(2 files, 1 obsolete file)

Attached file scrolling.html
Steps to reproduce:
1. Load the attached test case in Firefox and be sure the first line is at the top of the window.
2. Launch Accerciser
3. In Accerciser, select the second child element (ROLE_SECTION) of the document frame in Accerciser's tree of accessibles.
4. In Accerciser's iPython console, type acc.queryText().setCaretOffset(4) to set the caret at offset 4 in the div which is scrolled off screen.

Expected result: The line in which the caret was placed would be scrolled into view.

Actual result: The caret is successfully placed in the div which is scrolled off screen, but that div is not scrolled into view.

Impact: An AT that controls navigation (like the Orca screen reader) is often presenting content which is not visible -- no problem for a user who is blind and working alone. But if the Orca user is working with a sighted peer, or using Orca along with magnification software which tracks the caret location, that peer or low vision user cannot see what is being presented.
Blocks: orca
Another impact: There are dynamic pages in which additional content is displayed when the user scrolls towards the bottom of the page. DuckDuckGo search results is one such page.

Orca sets the caret position via AtkText as the user navigates. If where the caret is being set is a non-focusable element, Firefox won't scroll the page and the additional content won't be displayed until the user scrolls (e.g. via Page Down).
Please raise the priority of this bug. Sometimes, it's not just a minor inconvenience, but the user actually needs to click something that he/she reads, and that is impossible if it's off the screen.
Yes, it's bad authoring if an active element haven't been made focusable or doesn't react to the keyboard, but that's the real world.
Thanks for your understanding.
I'm visual impaired and I use the Gnome Zoom Applet, it's very lack of time to scroll with mouse in the same time as Orca.

For your information in Thunderbird, both in mail and web view from feeds I haven't this issue.

Best regards.
Attached patch proposed fix (obsolete) — Splinter Review

Here is a working patch: HyperTextAccessible.cpp is simply missing calling ScrollIntoView to make sure that the new focus is visible, just like nsFrameSelection::MoveCaret does for normal keypresses.

Attachment #8910749 - Flags: a11y-review?(surkov.alexander)
Attachment #8910749 - Flags: review?(surkov.alexander)
Comment on attachment 8910749 [details] [diff] [review]
proposed fix

Review of attachment 8910749 [details] [diff] [review]:

looks good
Attachment #8910749 - Flags: review?(surkov.alexander)
Attachment #8910749 - Flags: review+
Attachment #8910749 - Flags: a11y-review?(surkov.alexander)
Assignee: nobody → samuel.thibault
Hello Samuel,

Please update your commit message to match the desired format[1] and include author information in your patch.

Flags: needinfo?(samuel.thibault)
Keywords: checkin-needed
Attached patch proposed fixSplinter Review
Here is the same patch reworked with proper commit line and author
Attachment #8910749 - Attachment is obsolete: true
Flags: needinfo?(samuel.thibault)
Attachment #8917282 - Flags: checkin?(MattN+bmo)
Keywords: checkin-needed
Attachment #8917282 - Flags: checkin?(MattN+bmo)
Pushed by
On accessibility SetSelectionRange, scroll the selection into view. r=surkov
Keywords: checkin-needed
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
You need to log in before you can comment on or make changes to this bug.