MS Excel (with object model) lags behind when navigating rapidly #14983
Comments
|
After first quick research, reverting the change in keyboardHandler fixed this: From #14708:
Looks to me that this might be the way to go? |
|
I trust your regression hunting, but that's a bizarre manifestation of the problem. I can't follow why pressing left arrow would end up sending right arrow... or something? Does this commit fix it? jcsteh@91620fb |
It's not that bizarre actually. When using the object model, there are NVDA scripts bound to the arrow keys that do gesture.send and then report the newly focused cell. However it looks like in this case, gesture.send returns before Excel has processed the injected keys and therefore NVDA reports the cell that was focused last, since it has strictly spoken still the focus when reporting it.
Unfortunately, it doesn't. |
|
Does the Excel code wait for any kind of change or does it just assume the change happens as soon as the gesture gets sent? The latter feels wrong even despite the keyboardHandler change. There's no guarantee that Excel actually processed the change yet. That's why we have all the caret check stuff for text boxes. |
|
To put that another way, maybe we should put a time.sleep in the Excel scripts. |
Nope, it does not. So makes sense to me to come with a fix in that direction. Reintroducing the time.sleep will probably fix this, but it is more of a workaround than a real fix. |
|
Actually I was wrong, it does check for changes but it doesn't really work as expected. I will dive into it later this week. |
|
Also, if the delay is needed, I don't get why it wouldn't be failing constantly. In your case, it only seems to fail after holding down a key for a while. Why would Excel be slower after you release the held key and then press another one? |
|
The code was using the focus object to cache the old selection, so if the focus object was one cell behind, the logic would always find out a new selection since the old selection it used was wrong. So it looks like the keyboardHandler sleep you removed was obfuscating a bug we can now fix properly. |
Fixes #14983 Fixes #12200 Fixes #12108? Summary of the issue: Moving rapidly in Excel can result in lagging one cell behind when reporting focus. Description of user facing changes Rapid movement in Excel will now always report the last cell. Description of development approach First and foremost, NVDA was relying on the current focus object to cache the current selection in Excel rather than getting the current selection before executing the gesture. This resulted in the one behind behavior. There was logic to check for selection changes, but it detected a change based on the wrong old selection. I also revamped the logic a bit based on #14708, i.e. perform three attempts before doing a time.sleep.
Steps to reproduce:
Actual behavior:
NVDA reports R1 before pressing left arrow, but the actual cell is S1. When pressing left arrow, NVDA Reports S1, but the actual cell is R1.
Expected behavior:
NVDA reports s1 before pressing left arrow, the actual cell is S1. When pressing left arrow, NVDA Reports r1, the actual cell is R1.
NVDA logs, crash dumps and other attachments:
System configuration
NVDA installed/portable/running from source:
Installed
NVDA version:
alpha-28376,444b5688
Windows version:
Windows 11 22H2 (OS Build 22621.1702)
Name and version of other software in use when reproducing the issue:
Excel 365 16.0.16501.20196
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. In NVDA 2023.1 and below, NVDA sometimes reports the wrong cell when holding right arrow (str1), but the next movement is always reported correctly.
If NVDA add-ons are disabled, is your problem still occurring?
Yes
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
Yes
The text was updated successfully, but these errors were encountered: