UIA in Windows consoles: spaces are stripped from end of line, blank reported when arrowing through them

[LeonarddeR]

cc @codeofdusk

Steps to reproduce:

With UIA enabled in Windows consoles, type multiple spaces and arrow back.

Actual behavior:

NVDA reports blank for every press of left arrow

Expected behavior:

NVDA reports space for every press of left arrow

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

Alpha alpha-18290

Windows version:

Windows 10 1903 build 18362.239

Name and version of other software in use when reproducing the issue:

Windows command prompt (cmd)

Other questions

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

No

[AAClause]

Any news on this?

[michaelDCurran]

Please note that Windows consoles do not store space characters at all. If space is typed and or programmatically written, the character cell at that position is just left blank.
We should possibly return a space character for UIA text ranges that are blank in TextInfo.text. This at least will say 'space' for spaces in the middle of a line like it used to. However, spaces at the end of a line will be impossible as the UIA text ranges for a line don't cover the full terminal width, rather they only go up to the last non-space character on the line.
If the in-line space issue was fixed, would you consider allowing this issue to be closed as fixed, even though spaces at the end of the line (which again don't really exist anyway) was not fixed?

[codeofdusk]

Please note that Windows consoles do not store space characters at all. If space is typed and or programmatically written, the character cell at that position is just left blank.
We should possibly return a space character for UIA text ranges that are blank in TextInfo.text. This at least will say 'space' for spaces in the middle of a line like it used to. However, spaces at the end of a line will be impossible as the UIA text ranges for a line don't cover the full terminal width, rather they only go up to the last non-space character on the line.
If the in-line space issue was fixed, would you consider allowing this issue to be closed as fixed, even though spaces at the end of the line (which again don't really exist anyway) was not fixed?

I'd be happy with this solution – it also seems to have the added bonus of more accurately reflecting the console's contents.