Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MS Word - Commands to navigate to start or end of row or column do not report the correct cell anymore #15805

Closed
CyrilleB79 opened this issue Nov 20, 2023 · 4 comments · Fixed by #15809
Labels
p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation.
Milestone

Comments

@CyrilleB79
Copy link
Collaborator

CyrilleB79 commented Nov 20, 2023

Steps to reproduce:

  • Open a Word document and create a table (e.g. 4x4) with some content in each cell
  • Use the native Word commands to jump to the start or the end of row or column, i.e. Alt+Home, Alt+End, Alt+PgUp and Alt+PgDown

Actual behavior:

The content of the cell before the move is reported instead of the content of the landing cell.

Expected behavior:

The content of the landing cell should be reported instead.

NVDA logs, crash dumps and other attachments:

N/A

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2023.3

Windows version:

Windows 10 22H2 (AMD64) build 19045.3570

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

Microsoft® Word 2016 (16.0.5413.1000) MSO (16.0.5413.1000) 32 bits
and
Microsoft® Word 2016 MSO (Version 2310 Build 16.0.16924.20054) 32 bits

Other information about your system:

N/A

Other questions

Does the issue still occur after restarting your computer?

Not tested

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

NVDA 2023.2 NOK.
NVDA 2023.1 OK.

Thus it may be a regression of 2023.2 dev cycle.
From the change log, I imagine that #14708 or #14928 may have caused this regression, or just modified the timings so that a hidden bug has been uncovered. I have not bissected all the commits between 2023.1 and 2023.2 however.
Cc @jcsteh, any idea?

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?

Not tested

@jcsteh
Copy link
Contributor

jcsteh commented Nov 21, 2023

This seems a lot like #14984. This was probably "regressed" by #14708, though the bug was likely always present, just not exposed. Before #14708, gesture.send() did a sleep after sending the gesture, which caused performance problems. Now, it doesn't. That means that the code needs to wait for the application to update, rather than assuming it is up to date as soon as the gesture is sent. I haven't looked at the MS Word code in question, but that's my guess.

If I'm correct, note that this was always possible if the application took longer than 20-30 ms to update; e.g. if the system was under load. It's just more likely now.

@CyrilleB79
Copy link
Collaborator Author

This seems a lot like #14984. This was probably "regressed" by #14708, though the bug was likely always present, just not exposed. Before #14708, gesture.send() did a sleep after sending the gesture, which caused performance problems. Now, it doesn't. That means that the code needs to wait for the application to update, rather than assuming it is up to date as soon as the gesture is sent. I haven't looked at the MS Word code in question, but that's my guess.

If I'm correct, note that this was always possible if the application took longer than 20-30 ms to update; e.g. if the system was under load. It's just more likely now.

Yes, the code uses gesture.send() and immediately after, it retrieves text info at the caret's position to speak the new cell's content. There is no delay nor check to let the application enough time to update, what was not a visible problem in NVDA 2023.1 due to NVDA's intrinsic delays.

@jcsteh
Copy link
Contributor

jcsteh commented Nov 21, 2023

An interim fix would be to just add a time.sleep after the gesture.send, restoring the previous behaviour. The more correct fix is to actually make sure the cursor moved.

@CyrilleB79
Copy link
Collaborator Author

I am currently coding a fix inspired from what was done in Excel, i.e. wait until the cursor has moved to report the move.

@seanbudd seanbudd changed the title MS Word - Commands to navigate to start or end of row or column od not report the correct cell anymore MS Word - Commands to navigate to start or end of row or column do not report the correct cell anymore Nov 21, 2023
@seanbudd seanbudd added p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation. labels Nov 21, 2023
seanbudd pushed a commit that referenced this issue Nov 22, 2023
…5809)

Closes #15805

Summary of the issue:
In older versions of NVDA, NVDA was providing a speech feedback of the landing cell when using Word native commands for table navigation to jump to first or last cell of row or column: alt+home, alt+end, alt+pgUp and alt+pgDown. From NVDA 2023.2 onwards, this speech feedback is erroneous and reports the origin cell instead of the landing one. This is because the script for this commands was not robust and was taking advantage of existing delays in NVDA processing. in NVDA 2023.2 these delays have been reduced what uncovered this bug.

Description of user facing changes
The landing cell will be reported correctly again when using native Word table navigation to jump to first or last cell of row or column.

Description of development approach
Strategy inspired from #14984: send the gesture and check if the cursor location has changed before reporting its new position. If the cursor does not move, e.g. because you call a command to jumpt to first cell while you are already on the first cell, the current cell is reported after a maximum delay set to 0.15 seconds (same value as some other polling scripts).
@nvaccessAuto nvaccessAuto modified the milestone: 2024.1 Nov 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants