Vertical quick navigation throws errors in some cases

[cary-rowen]

Steps to reproduce:

1. Open the nvaccess homepage: https://www.nvaccess.org
2. Assign gestures to "moves to the next/Previous vertically aligned paragraph"
3. Press letter B in nvaccess homepage to quickly navigate to the "copy link" button or the "play" button.
4. Press the gesture assigned in step (2).

Actual behavior:

NVDA throws an error and the log is as follows:

Input: kb(laptop):b
IO - speech.speech.speak (12:37:33.171) - MainThread (12788):
Speaking ['Play', 'Button']
DEBUG - speech.manager.SpeechManager._handleIndex (12:37:33.189) - MainThread (12788):
Unknown index 2359, speech probably cancelled from main thread.
IO - inputCore.InputManager.executeGesture (12:37:34.261) - winInputHook (7368):
Input: kb(laptop):z
ERROR - scriptHandler.executeScript (12:37:34.556) - MainThread (12788):
error executing script: <bound method BrowseModeTreeInterceptor.addQuickNav.<locals>.<lambda> of <NVDAObjects.IAccessible.chromium.ChromeVBuf object at 0x1BC95FF0>> with gesture 'z'
Traceback (most recent call last):
  File "scriptHandler.pyc", line 295, in executeScript
  File "browseMode.pyc", line 564, in <lambda>
  File "browseMode.pyc", line 522, in _quickNavScript
  File "browseMode.pyc", line 479, in _iterSimilarParagraph
  File "browseMode.pyc", line 506, in paragraphFunc
  File "baseObject.pyc", line 41, in __get__
  File "textInfos\offsets.pyc", line 513, in _get_pointAtStart
  File "virtualBuffers\gecko_ia2.pyc", line 76, in _getBoundingRectFromOffset
  File "virtualBuffers\__init__.pyc", line 180, in _getBoundingRectFromOffset
LookupError: Object is off screen, invisible or has no location

Expected behavior:

No error should be thrown anyway.

NVDA logs, crash dumps and other attachments:

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

alpha-31344

Windows version:

Windows 10 22H2 (AMD64) build 19045.4046

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

Chrome: 122.0.6261.96

Other information about your system:

None

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.

No

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

[cary-rowen]

cc @mltony
Thanks for adding this feature to NVDA, could you please take a look at this issue?

[cary-rowen]

Hi cc @mltony
Testing #16276 using the same steps as in the original description observed the following information.

Input: kb(laptop):z
DEBUG - watchdog._waitUntilNormalCoreAliveTimeout (10:38:07.914) - watchdog (14956):
Potential freeze, waiting up to 10 seconds.
IO - speech.speech.speak (10:38:08.255) - MainThread (11792):
Speaking ['no next vertically aligned paragraph']
DEBUG - speech.manager.SpeechManager._handleIndex (10:38:08.257) - MainThread (11792):
Unknown index 169, speech probably cancelled from main thread.
DEBUGWARNING - RPC process 8736 (chrome.exe) (10:38:08.262) - Dummy-12 (9652):
Thread 12448, build\x86_64\vbufBase\storage.cpp, VBufStorage_buffer_t::getLineOffsets, 1068:
Offset of 4145 too big for buffer, returning false

DEBUG - watchdog._waitUntilNormalCoreAliveTimeout (10:38:08.415) - watchdog (14956):
Recovered from potential freeze after 1.0012990000250284 seconds.

Is this expected?

[mltony]

Yes. This command is slower than your typical QuickNav commands because it retrieves x coordinate of each paragraph in a separate call to chrome. So it takes about a second to complete and watchdog notices a freeze but then successfully recovers.

[XLTechie]

Would there be any way to prefetch in a background thread? E.g. if it is used once, expect it will be used again and prefetch the next few, and cache the previous few?

[mltony]

In theory yes. I suppose we could dig into C++ layer and have it prefetch x coordinate always.
In practice I would question cost vs benefit. Sean assessed this command to be only marginally important and not deserving a default keystroke - is it worth to optimize it then?

[XLTechie]

A reasonable point. Maybe some time in the wild will tell.