Some UIA text ranges have no apparent bottom

[codeofdusk]

Steps to reproduce:

In various modern UIA text providers (notepad with UIA forceably enabled with nav.appModule.isGoodUIAWindow = lambda hwnd: True in console), an upcoming/private build of conhost, and Word/Edgium with UIA enabled):

1. Navigate to the last line of text with the review cursor.
2. Attempt to move to the next line of text.

Actual behavior:

The review cursor is moved to the end of the current line, and "bottom" is not announced. Technical: UIATextInfo.move (IUIAutomationTextRange::move) returns 1.

Expected behavior:

"bottom" is announced.

Context:

It seems that, per Microsoft Word's behaviour (other UIA providers are copying this): when moving a degenerate (collapsed) range past the end of the document, the correct UIA behaviour is to permit the move and move to the end of the requested unit, whereas expanded ranges should not permit the move when attempting to go past the end. Is this correct UIA behaviour (the docs seem unclear) and therefore an NVDA bug, or are providers incorrectly implementing this (so I should raise it upstream)? Cc @csauls, @michaelDCurran and @LeonarddeR.

[codeofdusk]

Also CC @carlos-zamora (he is implementing according to Word's behaviour in conhost as part of microsoft/terminal#11122).

[carlos-zamora]

A few notes from my findings:

• Moving a degenerate range forward on the bottom line always succeeds and results in a degenerate range at the end of the document
• Moving a non-degenerate range similarly fails to move, but modifies the text range to still "expand" by the given unit. Seems like the philosophy is "you're already on the last line, there is no next full line to move to"
• This is specifically an observation for UIA text providers. Particularly, we've tested MS Word and Notepad. If you use the legacy pattern, you may get a different behavior.

This leads me to believe that there might have been a change in design or expected behavior for UIA. Nonetheless, I'm inclined to say that this is the correct behavior as I have yet found a UIA text provider that behaves differently.

[LeonarddeR]

@codeofdusk Can you reproduce this with older versions of NVDA?

[codeofdusk]

Looking around, I agree with the assessment by @carlos-zamora that much of the review cursor code was written without taking UIA into account (it's been present since at least commit 200bf5c in 2009).

Changing the code in globalCommands.script_review_previousLine/nextLine/etc to collapse first, then expand by line, then move yields correct behaviour in Word and modern conhost, but breaks review in MSAA controls.