NVDA is unresponsive/blocking during the timeout period when the update add-on notifies the connection server.

[hwf1324]

Recently, a large number of users encountered this problem after upgrading to 2024.3 because the Chinese community mirror server ran out of traffic. I think this is the same for not being able to access the NV Access server.

Steps to reproduce:

1. Install the NVDA Chinese Community Update Mirror add-on and restart NVDA.
2. Wait for the update add-on to check, during which you can keep pressing the key.

Actual behavior:

When connecting to the server during a timeout. Unable to operate the computer, NVDA is blocked.

Expected behavior:

Does not block NVDA

NVDA logs, crash dumps and other attachments:

DEBUG - utils.schedule.callJobOnThread (14:39:00.423) - ScheduleThread (23312):
Starting thread for job: _checkForUpdatableAddons on GUI thread
DEBUG - gui.addonStoreGui.controls.messageDialogs.UpdatableAddonsDialog._checkForUpdatableAddons (14:39:00.424) - MainThread (20796):
checking for updatable add-ons
DEBUG - addonStore.dataManager._DataManager._getCacheHash (14:39:00.425) - MainThread (20796):
Fetching add-on data from https://nvaccess.mirror.nvdadr.com/addonStore//cacheHash.json
IO - inputCore.InputManager.executeGesture (14:39:00.600) - winInputHook (24348):
Input: kb(laptop):downArrow
IO - inputCore.InputManager.executeGesture (14:39:02.382) - winInputHook (24348):
Input: kb(laptop):downArrow
IO - inputCore.InputManager.executeGesture (14:39:02.675) - winInputHook (24348):
Input: kb(laptop):upArrow
...
IO - inputCore.InputManager.executeGesture (14:39:05.445) - winInputHook (24348):
Input: kb(laptop):leftArrow
IO - inputCore.InputManager.executeGesture (14:39:05.461) - winInputHook (24348):
Input: kb(laptop):downArrow
IO - inputCore.InputManager.executeGesture (14:39:05.574) - winInputHook (24348):
Input: kb(laptop):rightArrow
IO - inputCore.InputManager.executeGesture (14:39:05.889) - winInputHook (24348):
Input: kb(laptop):upArrow
DEBUGWARNING - addonStore.dataManager._DataManager._getCacheHash (14:39:21.509) - MainThread (20796):
Unable to get cache hash: HTTPSConnectionPool(host='nvaccess.mirror.nvdadr.com', port=443): Max retries exceeded with url: /addonStore//cacheHash.json (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x0BE54770>, 'Connection to nvaccess.mirror.nvdadr.com timed out. (connect timeout=120)'))
DEBUG - addonStore.dataManager._DataManager._getLatestAddonsDataForVersion (14:39:21.510) - MainThread (20796):
Fetching add-on data from https://nvaccess.mirror.nvdadr.com/addonStore//zh_CN/all/2024.3.0.json
DEBUGWARNING - addonStore.dataManager._DataManager._getLatestAddonsDataForVersion (14:39:42.594) - MainThread (20796):
Unable to fetch addon data: HTTPSConnectionPool(host='nvaccess.mirror.nvdadr.com', port=443): Max retries exceeded with url: /addonStore//zh_CN/all/2024.3.0.json (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x0D1D4610>, 'Connection to nvaccess.mirror.nvdadr.com timed out. (connect timeout=120)'))
DEBUG - editableText.EditableText._hasCaretMoved (14:39:43.356) - MainThread (20796):
Caret move detected using bookmarks. Elapsed 0 sec, retries 0

System configuration

NVDA installed/portable/running from source:

install/portable

NVDA version:

2024.3 and versions with updated add-on notifications

Windows version:

Windows 11
Version 22H2 (OS internal version 22621.4037)

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

Other information about your system:

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

If NVDA add-ons are disabled, is your problem still occurring?

yes, it should also work for cases where you can't access the NV Access server.

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

yes

[cary-rowen]

cc @seanbudd

Before this, users had already reported this issue during the RC and Beta stages. At that time, these users were not utilizing the NVDA Chinese community mirror service.
We did not pay much attention to the problem initially because the users were unable to provide specific reproduction steps or logs for analysis.
The issue became more apparent when the NVDA Chinese community mirror service traffic was exhausted. A large number of users in the NVDA Chinese community reported that NVDA stopped working after updating to version 2024.3.

This issue might warrant a higher priority. We are currently advising users to temporarily disable add-on update notifications.

[XLTechie]

@seanbudd Perhaps the check should be run on the daemon thread, and should trigger an extensionPoint to fire the GUI portion once it is known whether there are updates?

[cary-rowen]

cc @SaschaCowley

[seanbudd]

Can you please test this PR and see if it works as expected: https://ci.appveyor.com/api/buildjobs/pnr3dy4800nq6993/artifacts/output%2Fnvda_snapshot_try-fixAddonUpdateBG-33534%2C09eaf81e.exe

[hwf1324]

I reproduced the environment by redirecting nvaccess.org to 127.0.0.1 in the Host file.

From testing so far, this Issue seems to be resolved.

[cary-rowen]

Hello,

CC @seanbudd
I noticed this was merged into 2024.3.1 Will we consider releasing this version?

[seanbudd]

Yes - we were just waiting for alpha/beta testing. 2024.3.1 will be released next monday