Find in webpages inaccurate in the presence of certain characters

[ajirving]

Steps to reproduce:

ON certain webpages use NVDA's find functionality with ctrl+nvda+f to search for text. I think the pages with the bad behaviour are those containing special characters like Emoji's. If there's just a couple of special characters then you're usually close to the text you searched for but for particularly bad behaviour see https://github.com/ikatyang/emoji-cheat-sheet/blob/master/README.md and try to search for geometric

Actual behavior:

The cursor is several characters before the text you searched for, the distance seems to be proportional to the number of special characters in the way.

Expected behavior:

The cursor is on the start of the text.

NVDA logs, crash dumps and other attachments:

System configuration

NVDA installed/portable/running from source:

Verified with both installed and running from source.

NVDA version:

2023.3.4 but has been present in older versions for a long time.

Windows version:

Windows 11

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

Can reproduce in either Chrome or Edge.

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.

Yes, same behaviour in older versions.

If NVDA add-ons are disabled, is your problem still occurring?

N/A

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

N/A

Comment

I've been aware of this behaviour for some time but only just realized that the trigger seems to be the presence of special characters. I haven't looked at the code but wonder if there's some sort of indexing issue because these characters will be taking up multiple bytes.

[CyrilleB79]

Confirmed on my side both with Firefox and Chrome.
The issue occurs with emojis (or probably other less frequent characters with high Unicode codepoint).

The issue is present since the first Python 3 version of NVDA, i.e. 2019.3 and was not present in last Py2 version (NVDA 2019.2.1).

Cc @LeonarddeR; I think that you have worked on these aspects of offsets in the past.

Here is a simple test URL:
data:text/html,<meta charset="utf8"><p>abcd%F0%9F%90%95%F0%9F%90%95%F0%9F%90%95efgh</p>

[ajirving]

This is definitely caused by the extra size required by utf-32 characters. If you use nvda+delete to get your percentage in the document you can see that the value increases by twice as much on the emojis.

The virtual buffer code which is mostly in C++ seems to use wchar (so UTF-16) strings and the offsets are all relative to those. Thus it thinks the UTF-32 characters require two positions. The find functionality is implemented in Python so gives a correct offset relative to the unicode string. I don't know enough about the code to say what the best fix is.

[Adriani90]

Is this issue related to #12256?

[CyrilleB79]

@LeonarddeR or @mltony is it related / can it be solved by your recent work on moving to codepoint offset?

[LeonarddeR]

Possibly, but I think we need to use an offset converter instead.

[jcsteh]

The adjustment could be done with something like this for forward searches in textInfos.offsets.OffsetsTextInfo.find:

# Python uses Unicode code points, but the offsets are based on UTF-16.
# 32 bit Unicode characters are two code points in UTF-16.
# Therefore, add 1 additional offset for every 32 bit character.
offset += sum(1 for c in inText[:m.start()] if c >= '\U00010000')

The reverse case would be similar, but... it's getting late and I can't quite get my head around it right now. :)

[LeonarddeR]

Update: Removed something about surrogates that didn't make sense
As proposed above, it is probably easiest and nicest to change find in such a way that it uses _getOffsetEncoder to get the appropriate offset converter and then convert the offsets as generated by the regex find to the appropriate offsets that match the internal encoding of the textInfo.
That should actually be pretty trivial to implement.