Python 3: when in UIA based edit field, the deleted character is not spoken when pressing backspace

[zstanecic]

Steps to reproduce:

1. go to any edit field, for example, skype chat, unigram chat, and or windows mail UIA app
2. write something
3. press backspace

Actual behavior:

the deleted caracter is not voiced

Expected behavior:

deleted character should be voiced

System configuration

NVDA installed/portable/running from source:

portable

NVDA version:

latest treshold py3 staging

Windows version:

windows 10 1903

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

not applicable

Other information about your system:

n/a

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 and not applicable, as it works in alpha snapshots

[LeonarddeR]

Can you please test this with a portable copy of normal threshold (not the py3 staging branch)?

[zstanecic]

Yes, please give me the time, as i am waiting for compilation.

[LeonarddeR]

I was not able to reproduce this on latest threshold before Python 3 was merged in. Interesting ehough, I thought it was caused by me changing the postCaretMovedScriptHelper, but that doesn't seem to be the case.

[zstanecic]

I am waiting for the mege. I will see when it merges to threshold

[zstanecic]

Nope, I’ve testing it now with treshold, and it is not fixed there. It is a regression

[LeonarddeR]

Ive been able to look into this some more, and it's pretty complicated.

The issue is in editableText.EditableText, line 101: if newBookmark and newBookmark!=bookmark:

First, let's try to explain something like a code example. For this, type hello into a word document and paste this into a python console:

x=nav.makeTextInfo("caret")
x==x
x!=x
y=x.copy()
x==y
x!=y
y.move("character", -1)
x==y
x!=y

Output under Python 2 is as follows:

>>> x=nav.makeTextInfo("caret")
>>> x==x
True
>>> x!=x
False
>>> y=x.copy()
>>> x==y
True
>>> x!=y
True
>>> y.move("character", -1)
-1
>>> x==y
False
>>> x!=y
True

Output under Python 3:

>>> x=nav.makeTextInfo("caret")
>>> x==x
True
>>> x!=x
False
>>> y=x.copy()
>>> x==y
True
>>> x!=y
False
>>> y.move("character", -1)
0
>>> x==y
True
>>> x!=y
False

The important case and only difference here is the first occurrence of x!=y, which is True on Python 2 and False on Python 3. I'm pretty sure that this insconsistency in the __eq__ and __neq__ operator clarify this issue.
Actually, a positive and negative comparison could never be True both as is the case on Python 2. So, this code has probably never worked as it really should have worked in the first place.

Cc @feerrenrut

[LeonarddeR]

Another example:

1. In word, type hello
2. Position caret at the start of the line
3. a=nav.makeTextInfo("caret")
4. In the word document, press right arrow
5. b=nav.makeTextInfo("caret")
6. Now, a==b is False
7. In the word document, press backspace
8. Now, a==b is True.

This Compare method on UIA Text Ranges really behaves a bit strange. I'm afraid it is not very safe to rely on it for our equality comparison.

[zstanecic]

Is it a showstopper? @LeonarddeR

[LeonarddeR]

Somehow yes, but I've already been able to come up with something that fixes it.

[feerrenrut]

Fixed in commit 75c8d00 via PR #9933