Created attachment 8613622 [details] 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.
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.
Created attachment 8910749 [details] [diff] [review] proposed fix Hello, 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. Samuel
Comment on attachment 8910749 [details] [diff] [review] proposed fix Review of attachment 8910749 [details] [diff] [review]: ----------------------------------------------------------------- looks good
Assignee: nobody → samuel.thibault
Status: NEW → ASSIGNED
Hello Samuel, Please update your commit message to match the desired format and include author information in your patch.  https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Committing_Rules_and_Responsibilities#Commit_message_restrictions
Created attachment 8917282 [details] [diff] [review] proposed fix Here is the same patch reworked with proper commit line and author
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/9cbc9faa5c99 On accessibility SetSelectionRange, scroll the selection into view. r=surkov
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox58: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
You need to log in before you can comment on or make changes to this bug.