Config upgrade/speak typed characters and words: keys "speakTypedCharacters" and "speakTypedWords" are of the wrong type

[josephsl]

Hi,

Critical alpha regression after merge of #17505:

Steps to reproduce:

1. Upgrade from a previous alpha to alpha-35064,605db3e4.
2. NVDA displays a configuration error message when restarted.

Actual behavior:

NVDA restores default settings due to value/type mismatch in speak typed characters/words.

Expected behavior:

Speak typed characters and words settings are migrated properly.

NVDA logs, crash dumps and other attachments:

ERROR - config.ConfigManager.initBaseConf (22:10:00.070) - MainThread (28856):
Error loading base configuration; the base configuration file will be reinitialized. A copy of your previous configuration file will be saved at C:\Users\User\AppData\Roaming\nvda\nvda.ini.corrupted.bak
Traceback (most recent call last):
File "config_init.pyc", line 582, in initBaseConf
File "config_init.pyc", line 633, in loadConfig
File "config_init.pyc", line 629, in _loadConfig
File "config\profileUpgrader.pyc", line 27, in upgrade
File "config\profileUpgrader.pyc", line 68, in _doValidation
ValueError: Unable to validate config file after upgrade: Key speakTypedCharacters : the value "False" is of the wrong type.

The above traceback repeats if "speakTypedWords" value/type mismatch occurs (which is on my system as I turn both settings off).

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

alpha-35064,605db3e4

Windows version:

Windows 11 24H2 dev Insider (build 26120.2992)

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

None

Other information about your system:

Used as a development workstation

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 issues in prior alphas

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

Possible cause:

I suspect config upgrade is at fault in that bool to integer conversion for typing echo settings are not translated correctly.

Thanks.

[Adriani90]

cc: @cary-rowen

[cary-rowen]

Sorry for introducing this regression.
I installed nvda_alpha-35059,098863bd and then upgraded to alpha-35064,605db3e4 as instructed and did not reproduce this.
@josephsl
Do you or anyone else have any more information or suggestions for reproducing this issue?

[seanbudd]

@cary-rowen - it's a merge conflict between #17598 and #16848 , we both had a config upgrade step for the same schema version

[cary-rowen]

Thanks @seanbudd

To be honest, I don’t quite understand the real reason for the conflict between #17598 and #17505.

#17598 seems to just delete the configuration and does not need to provide upgrade steps.

What are the best practices and what actions can we take for this situation?

[SaschaCowley]

@josephsl can you please provide a copy of your old nvda.ini?

[josephsl]

nvda.txt

[josephsl]

Hi,

This is nvda.ini (renamed to .txt) from NVDA 2024.4.2 RC 1.

[SaschaCowley]

@josephsl I can't replicate the error you're experiencing. My testing methodology was as follows:

Minimal: Ran NVDA from source (master checked out). Imported configobj and the profile upgrade steps. Instantiated a ConfigObj with your config file, then called upgradeConfigFrom_14_to_15 on it. The config was upgraded successfully.

Portable: Created a portable copy of NVDA based on a version without the typing echo PR. Copied your config file into its userConfig directory (renaming to nvda.ini). Ran the portable to make sure the config was in place. Updated the portable to a version of NVDA with the typing echo commit in place. I tested the following versions:

• Portable created from alpha-35059,098863bd, upgraded to alpha-35071,93bbe4f9 via the update checker.
• Portable created from alpha-35059,098863bd, upgraded to alpha-35064,605db3e4 from the launcher.
• Portable created from 2024.4.2rc1, upgraded to alpha-35064,605db3e4 from the launcher.

In all cases, the config was upgraded successfully.

Installed: Installed NVDA based on a version without the typing echo PR. Copied your config file into to %AppData%\nvda (renaming to nvda.ini). Ran NVDA to make sure the config was in place. Updated to a version of NVDA with the typing echo commit in place. I tested the following versions:

• Installed alpha-35059,098863bd, upgraded to alpha-35064,605db3e4 from the launcher.
• Installed alpha-35059,098863bd, updated to alpha-35071,93bbe4f9 via the update checker.

In both cases, the config was upgraded successfully.

@seanbudd do you have any thoughts?

[cary-rowen]

1. I created portable version 2024.4.2 and used the configuration provided by @josephsl to load NVDA.
2. Then, I manually installed nvda_snapshot_alpha-35059,098863bd.
3. Verified that the configuration was successfully upgraded to version 14.
4. Next, I used the updateChannel to switch to the Alpha channel and upgraded to alpha-35064,605db3e4.
5. The configuration was still successfully upgraded to version 15.

[josephsl]

Hi,

I can't reproduce this at the moment:

1. Open NVDA user config folder for the installed copy of alpha.
2. Quit installed copy of alpha-35071,93bbe4f9.
3. Started a portable copy of alpha-35071,93bbe4f9.
4. Opened nvda.ini file from the user config folder for the installed copy of NVDA in Notepad.
5. Modified the nvda.ini file to state schema version as 14 and set "speakTypedCharacters" and "speakTypedWords" to False and False, respectively, then saved the file.
6. Quit portable copy of alpha-35071,93bbe4f9.
7. Started installed copy of alpha-35071,93bbe4f9. This forced the config upgrade steps to be performed, this time with no errors.

I guess this could be something unique to my system and my config file. But I still think it would be good to have a backup plan as proposed in the pull request. Thanks.