@codeofdusk: It might be good to see what this scrolling code does in UIA consoles. Note that you will still have to trigger it manually though, as the review cursor commands do not yet scroll.

Here is a try build.

@codeofdusk: It might be good to see what this scrolling code does in UIA consoles. Note that you will still have to trigger it manually though, as the review cursor commands do not yet scroll.

Trying to scroll a textInfo into view that is beyond the first visible range (by calling its scrollIntoView method in the Python console) makes review unusable until the caret moves/new text is added. Knowing if text actually scrolls visually would require sighted input. Cc @feerrenrut

@codeofdusk: Could you elaborate on what you mean with makes review unusable?

@JulienCochuyt: You might be interested in this pr, since it will drastically improve scrolling behavior in web browsers for sighted users.

Using the About NV Access page (the address has changed from the original issue, but I think it's still the same page, and it does meet the criteria of having a large block of non-linked text): https://www.nvaccess.org/about-nv-access/

With NVDA 2019.2, both Firefox (68.0.2) and Chrome (76.0.3809.100), both scroll as I press the down arrow to move through text. Neither they, nor Edge scroll when using say all however.

Using this PR build, Edge now scrolls when I down arrow through the document, where it doesn't with 2019.2. Neither of the other browsers scroll with down arrow now, and none of them scroll during say all.

@feerrenrut can you confirm either my findings, or that I've gone mad?

Ah, I found it. Will try to come up with an appropriate fix. It also seems that using NVDA+delete is appropriate to test this nonvisually.

It turns out that IAccessibleTextObject.scrollSubStringTo fails in some cases, that is, it returns S_OK but still does not scroll. Pretty annoying, since it indeed causes a regression. This means that we could only scroll at the object level.

Is this a bug in Firefox, or do you see this in Chrome as well?

@Qchristensen Would you be able to retest this with the newest build?

note that say all is expected not to work. This is covered in #9937. I could consider putting this in a separate pull request, but I had to change some logic as part of #9937, so it made sense to do that now.

I think this should also fix #5881. Not sure about #6673, though, it might even make it worse.

about #6673, though, it might even make it worse.

This would go beyond my imagination, as the current effect is already quite drastic, especially when you simultaneously attempt to circumvent it using the mouse scroll wheel.

@LeonarddeR thanks for all the details.
Thus, I guess we are attempting here to alignToTop whenever moving from a visible object to an upper invisible object and alignToBottom when moving to a lower invisible object.
I consider here the origin of the move rather than the attempted direction on purpose: Eg. depending on the document structure, hitting the down arrow might move the virtual caret somewhere up.

@JulienCochuyt: sorry for me taking some time to get back to this.

Thus, I guess we are attempting here to alignToTop whenever moving from a visible object to an upper invisible object and alignToBottom when moving to a lower invisible object.

Exactly that.

I consider here the origin of the move rather than the attempted direction on purpose: Eg. depending on the document structure, hitting the down arrow might move the virtual caret somewhere up.

Could you elaborate with an example? Hitting down arrow while the caret is at the bottom should idially scroll the new text into view, leaving the caret at the bottom of the view port.

Could you elaborate with an example? Hitting down arrow while the caret is at the bottom should idially scroll the new text into view, leaving the caret at the bottom of the view port.

If you are browsing content presented in columns by any means, when moving down from the last line of a given column, your destination is the first line of the next column, thus alignToTop in this case.
A specific example is when the canva defines a region between the main content and the footer, visually anchored at the upper right corner of the main content.

I wrote this pull request on behalf of @BabbageCom. As I'm leaving @BabbageCom after the 29th of November, I can no longer afford maintaining this pr other than applying very basic review actions. If this pull request requires major changes, they will have to be applied by someone else, e.g. @JulienCochuyt, @sjfbol or whoever else is willing to take it.

@LeonarddeR As promised, I'll take care of this one (unless of course if @sjfbol is willing to)
I must concentrate on other projects right now with the upcoming of 2019.3, but this is definitely in our pipeline.
I guess you can leave this PR open for reference for now. When I'll return on polishing your code, I'll mark the new PR as superseding this one and closing it.

It's unlikely that @sjfbol will jump on this pr in the near future, so it would probably best if you do as suggested. I will Finnish this off with fixing the merge conflicts and then I'll leave this open.

As in the current Alphas fast browse mode became the default what effect would it have on this PR? Is it even possible to have working scrolling for partially sighted users and do not move focus in browse mode at the same time?

@lukaszgo1 wrote:

As in the current Alphas fast browse mode became the default what effect would it have on this PR? Is it even possible to have working scrolling for partially sighted users and do not move focus in browse mode at the same time?

As promised, I've started work on taking back this PR, but it requires a huge lot of testing for corner cases.
Theoretically, fast browse mode should not interfere as the focused object can always be safely scrolled out.
Still, thanks for drawing attention on this use case to include in the test suite.

@JulienCochuyt Any updates on the testing of this PR?

As it seems that this pr hasn't gained much attention by potential takers. Furthermore, when one takes over a pr, it is a common pattern that the old pr is closed in favour of a new one.

I'm closing this pull request to clean up the backlog, happy for anyone to reopen a pr based on this work if desired.

I think it would be very beneficial to have this work done, especially for visually impaired people and when working together with sighted people.
Given Internet explorer is discontinued, we don't need to set priority on IE anymore.
However, MsHTML is still being used in several places but nevertheless this PR would be a significant improvement to the current situation anyway.