Browse mode in MS Word with UIA: ensure scrolling and carret position are always synched#12829
Browse mode in MS Word with UIA: ensure scrolling and carret position are always synched#12829michaelDCurran wants to merge 3 commits into
Conversation
MS Word with UIA browse mode: override scrollToPosition to call scrollIntoview on IUIAutomationTextRange. Fixes #9611
See test results for failed build of commit 223e0f7957 |
|
@Qchristensen I had to revert the last fix for #9611 as it was a bit too broad for NVDA 2021.3. Could you therefore please test the following try build: https://ci.appveyor.com/api/buildjobs/6m157vcnkuuddl6c/artifacts/output%2Fnvda_snapshot_try-i9611_small-23726%2C69618f72.exe |
|
This try build doesn't implement the fix for me - I opened the Basic Training module and pressed NVDA+down arrow. The caret visually appeared to move while within the visible portion of the document. Once out of view, the document did not scroll at all. If I stopped say all with say an arrow key, it would jump to the current line it was reading IF that line was on the current page, but after that when I stopped say all the caret was back where I'd started. No error in the log. |
|
Was this in browse mode or focus mode?
You said you opened the basic training and pressed NVDA+downArrow. You
don't necessarily say that you enabled browse mode before pressing
NVDA+downArrow.
Still, even if you didn't enable browse mode, your findings suggests
that the document never scrolled in either mode when the caret is
programmatically set by NVDA.
In that case, I'll need to change the approach again.
|
|
Another question, I don't know if it is related to this, the braille cursor cannot be scrolled in focus mode. I will find a few devices to confirm this issue later, and then I will open an issue |
|
@michaelDCurran I'm glad I at least documented my process, even if I didn't READ what I was supposed to be doing this time around :) You are right, I was in focus mode for that previous test. So, I tried again and this time press NVDA+Spacebar before pressing NVDA+down arrow. In this case, the caret moved visibly while in the portion of the document visible on screen. The document did NOT visibly scroll once the caret moved past the bottom of the screen. When I stopped the say all however, the caret was in the expected place (say three and a half pages into the document) and the view jumped to that point as well. |
|
@Qchristensen Okay, can you please test another try build for me:
https://ci.appveyor.com/api/buildjobs/i2njo9v7u42600fl/artifacts/output%2Fnvda_snapshot_try-i9611_updateCaret-23760%2C1fee7baa.exe
Again, MS Word with UIA enabled. Testing say all in both browse mode and
focus mode.
Also quick nav in browse mode (e.g. h to move through headings).
|
|
With the new build: |
|
Replacing with #12851 |
Link to issue number:
Fixes #9611
Replaces pr #12803
Summary of the issue:
When reading / navigating with browse mode in Microsoft Word via UI Automation, the document does not always scroll so that the current browse mode position is visible on screen, nor does the focus mode caret position stay in sync with the browse mode caret, especially when moving across pages in browse mode.
Browse mode currently only knows how to scroll to objects in the document, not specific text range positions. Thus, it is only able to scroll to lists, tables and graphics, and not any arbitrary text.
Also, setting the caret in Microsoft Word to a range that is on a page that is currently off screen seems to fail and or set the caret to a random point on the current page.
Description of how this pull request fixes the issue:
browseMode.BrowseModeDocument: abstract the scrolling code out of_set_selectioninto its ownscrollToPositionmethod onBrowseModeDocument.Testing strategy:
Known issues with pull request:
This specifically addresses browse mode scrolling issues in MS Word with UIA enabled as these scrolling issues were also affecting syncing of the focus mode caret with the browse mode caret. But there remains scrolling issues in other apps, which have always existed. Pr #9919 goes much further in addressing all of these, but is rather complex and requires a lot more review and testing. This particular pr is much smaller and stays specific to what we need to unblock enabling UIA by default in MS Word.
Change log entries:
Bug fixes:
Code Review Checklist: