Incorrect behavior of TextInfo.updateCaret() in certain situations in Google Chrome.

[mltony]

Description

In chrome, when text in edit box has a blank line (two newline characters together), updateCaret() function of TextInfo may behave incorrectly. It seems like TextInfo.move() function works fine, but updateCaret() then fails to actually place the cursor to the actual location of textInfo. In particular, in the example below, it seems impossible to set cursor to any place beyond the first line.

Steps to reproduce:

1. Open any GitHub issue in Google Chrome, and navigate to new comment edit box (any multiline edit box would do).
2. Enter the following text, making sure there is a blank line separating the first and the last lines:

AB

CD

3.Press Control+Home and then Right Arrow to make sure system caret is at letter B.
4. Press NVDA+Control+Z to open python console.
5. Enter the following script:

t = focus.makeTextInfo(textInfos.POSITION_CARET)
t.move(textInfos.UNIT_CHARACTER, 1)
t.updateCaret()

6. Close python console.

Actual behavior:

Cursor is at letter A in the very beginning of the edit box.

Expected behavior:

Cursor should be in the very end of the first line, right after letter B.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2020.3

Windows version:

Windows 10

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

Google Chrome Version 87.0.4280.88 (Official Build) (32-bit)

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Yes

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

No

If addons are disabled, is your problem still occuring?

Yes

Did you try to run the COM registry fixing tool in NVDA menu / tools?

Yes

[cary-rowen]

Yes, I reproduced it here.

[mltony]

I also found that updateFocus() behavior is incorrect when any unicode character is present in the edit box. For example, another way to repro this issue is like this. Enter the following two lines into any edit box in Chrome:

test
hello world ≠

Position cursor in the beginning of the second line and try to move it anywhere using textInfo.move API. Then after calling updateCaret() function caret is not going to be where you would expect it to be.

[vortex1024]

I am a user of one of Tony's addons which suffers from this issue, and I would like to add my vote for prioritizing this.

[cary-rowen]

I am troubled by this problem and I hope to raise its priority.

[mltony]

I did some more investigation on this and managed to drill down to an underlying issue in chromium. I reported that issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=1260726

[aleventhal]

The Chromium bug has this note:

i'm unable to reproduce this with Chrome 122.0.6261.130 -- caretOffset returns 2 after a call to SetCaretOffset(2). OP: can you still repro?

Also:

i believe this was fixed with https://crrev.com/1002440 (https://issues.chromium.org/40191752), which first appeared in Chrome 103.0.5059.0. https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/1002468/ is the first chromium snapshot with the fix.
OP: do you still find that focus.IAccessibleTextObject.caretOffset doesn't return 2?

Does this still repro or can we close both bugs now?

[Adriani90]

In Google Chrome Canary this works as expected, tested with NVDA 2024.1 Beta 13. The bugs in Crhomium can be closed. I will close this one as well as works for me.
Thank you @aleventhal for the update, that's very appreciated.

[mltony]

It still reproduces on my Chrome. I updated chromium issue with my screencast.

[Adriani90]

@mltony there was some progress on that issue in Chromium, is this issue still reproducible in Canary 132 with NVDA 2024.4.1?

[cary-rowen]

Hi @Adriani90

You wrote:

there was some progress on that issue in Chromium, is this issue still reproducible in Canary 132 with NVDA 2024.4.1?

Where did you see Chromium's progress on this issue?

The original bug created by Tony has not been updated recently.

[mltony]

Actually this indeed can be closed - the issue as described here indeed doesn't reproduce anymore.
What we discovered in that chromium discussion is sort of an adjacent issue: that IAccessible.SetCaretOffset() call is not synchronous, that is it takes some time (in my measurement 30 ms) for the new caret offset to propagate inside chrome. We would need to make an explicit sleep statement to work around that. Judging by lack of response from Chromium team they are not planning to fix this.

[cary-rowen]

Hi @mltony

There are some new updates internally, probably after Thanksgiving. If you are planning to reopen a chromium bug or would like to provide some summary/overview in the original bug then it might be helpful.

[mltony]

@cary-rowen, chromium bug is still open - I didn't close that:
https://bugs.chromium.org/p/chromium/issues/detail?id=1260726#c2
I just thought that keeping this issue on NVDA tracker doesn't make much sensej especially since the description here is outdated. But LMK if having an open NVDA issue will open - I can create a new updated issue here.

[cary-rowen]

OK, just make sure that bugs in chromium can still be reproduced.