MS Word: braille display "table cell coordinates" sometimes lag

[nvaccessAuto]

Reported by surfer0627 on 2015-08-05 01:16
STR:

1. Open the attachment.
2. Press ctrl+page down (two times), move to page 3.
3. Press ctrl+alt+down arrows:
   Braille display "table cell coordinates" lag.

This won't happen when moving in page2 (row25 through row53).

In browse mode, I also got the same result.

[nvaccessAuto]

Attachment Table navigation test case.doc added by surfer0627 on 2015-08-05 01:20
Description:
Test case: braille display "table cell coordinates"

[nvaccessAuto]

Comment 1 by jteh on 2015-08-05 01:23
What do you mean by "braille display table cell coordinates lag"? Do you mean the display takes a while to update? How do you know this is to do with table cell coordinates?

[nvaccessAuto]

Comment 2 by surfer0627 (in reply to comment 1) on 2015-08-05 01:42
Replying to jteh:
Yes, I mean the display takes a while to update.

How do you know this is to do with table cell coordinates?

Actually, I do not know about it.
I point out it just because this is a blank table.
If we type some text in it, display also takes a while to update the content.

[surfer0627]

The following idea is coming from issue #5956:
Sometimes, when pressing Ctrl+Alt+Arrows to move to row/column. Speech report content first, and braille display content a little bit lag. In this case, if user press Ctrl+downArrow to move to next column. Braille will display content as speech do. Is it possible for NVDA to use Microsoft Word's own table move commands for browse mode table navigation?

[Adriani90]

@ehollig could you please add the attachments for this issue from the old issue tracker? Thanks.

[Adriani90]

So this issue suggests that speech is reporting the table cell content faster than it is displayed on the braille display, and this happens only when using ctrl+alt+arrow keys to move row by row or column by column.

cc: @aaclause could you please test if this is still occuring with NVDA last alpha?
This would be very appreciated.
Thanks.

[aaclause]

I confirm the issue. I have often experienced slow performance in Microsoft Word tables. Braille and speech.

I just retested with the table of 197 lines from this page (add-ons disabled): https://www.geograf.in/en/table.php
... and it is still the case.

The log reflects it accurately (see freezes):

IO - inputCore.InputManager.executeGesture (11:44:04.562) - winInputHook (12732):
Input: kb(laptop):control+alt+downArrow
DEBUG - watchdog._waitUntilNormalCoreAliveTimeout (11:44:04.647) - watchdog (14896):
Recovered from potential freeze after 1.0104921000000004 seconds.
DEBUG - watchdog._waitUntilNormalCoreAliveTimeout (11:44:05.068) - watchdog (14896):
Potential freeze, waiting up to 10 seconds.
IO - speech.speech.speak (11:44:05.627) - MainThread (10976):
Speaking ['ligne 28', 'Gitega\n']
DEBUG - UIAHandler.shouldUseUIAInMSWord (11:44:05.649) - Dummy-1 (19048):
Not using UIA in MS Word on pre Windows 11 OS due to missing custom extensions
DEBUG - watchdog._waitUntilNormalCoreAliveTimeout (11:44:06.096) - watchdog (14896):
Recovered from potential freeze after 1.527771399999999 seconds.
DEBUG - watchdog._waitUntilNormalCoreAliveTimeout (11:44:06.158) - watchdog (14896):
Potential freeze, waiting up to 10 seconds.
IO - braille.BrailleBuffer.update (11:44:06.202) - MainThread (10976):
Braille regions text: ['l28 c3 Gitega ']
IO - braille.BrailleHandler.update (11:44:06.202) - MainThread (10976):
Braille window dots: 123 126 1256 - 14 146 - 12457 24 2345 15 1245 1 -
IO - braille.BrailleHandler.update (11:44:06.203) - MainThread (10976):
Braille window dots: 123 126 1256 - 14 146 - 12457 24 2345 15 1245 1 -
IO - inputCore.InputManager.executeGesture (11:44:06.340) - winInputHook (12732):
Input: kb(laptop):control+alt+downArrow
DEBUG - watchdog._waitUntilNormalCoreAliveTimeout (11:44:06.671) - watchdog (14896):
Recovered from potential freeze after 1.012656100000001 seconds.
DEBUG - watchdog._waitUntilNormalCoreAliveTimeout (11:44:06.843) - watchdog (14896):
Potential freeze, waiting up to 10 seconds.
IO - speech.speech.speak (11:44:07.136) - MainThread (10976):
Speaking ['ligne 29', 'Phnom Penh\n']
DEBUG - UIAHandler.shouldUseUIAInMSWord (11:44:07.151) - Dummy-1 (19048):
Not using UIA in MS Word on pre Windows 11 OS due to missing custom extensions
DEBUG - watchdog._waitUntilNormalCoreAliveTimeout (11:44:07.345) - watchdog (14896):
Recovered from potential freeze after 1.0013417000000011 seconds.
DEBUG - watchdog._waitUntilNormalCoreAliveTimeout (11:44:07.673) - watchdog (14896):
Potential freeze, waiting up to 10 seconds.
IO - braille.BrailleBuffer.update (11:44:07.701) - MainThread (10976):
Braille regions text: ['l29 c3 Phnom Penh ']
IO - braille.BrailleHandler.update (11:44:07.701) - MainThread (10976):
Braille window dots: 123 126 246 - 14 146 - 12347 125 1345 135 134 - 12347 15 1345 125 -
IO - braille.BrailleHandler.update (11:44:07.701) - MainThread (10976):
Braille window dots: 123 126 246 - 14 146 - 12347 125 1345 135 134 - 12347 15 1345 125 -

Running on: Windows 10 22H2 (10.0.19045); NVDA version alpha-28179,345154a6; Office 16.0.16327.20214

[Adriani90]

cc: @burmancomp

[burmancomp]

Likely I should know but what I should do that I get that table from https://www.geograf.in/en/table.php to word so that it is shown as table?

I do not know why there are freezes. But at least in part of cases it seems that speech output is before moving caret and I guess that braille output comes after caret movement maybe this could cause some delay.

[hwf1324]

Maybe try https://www.nvaccess.org/files/nvdaTracAttachments/5266/ for the original attachment.

[burmancomp]

Maybe try https://www.nvaccess.org/files/nvdaTracAttachments/5266/ for the original attachment.

Thank you @hwf1324. I guess they used some different system, and then they have started to use github.

[hwf1324]

Yes, I read that in the project documentation.