A portable copy launched immediately after creation now correctly uses its own configuration

[CyrilleB79]

Link to issue number:

Closes #18442
Fix-up of #16937

Summary of the issue:

When creating a portable NVDA and asking to launch it immediately after creation, the portable copy does not use its own config, but the one of the NVDA it had been created from.

In #16937, we propagate --disable-addons as well as -c / --config-path for security reasons so that an administrator can update from a user account using their own config folder, without risking to use malicious add-ons in the user's configuration (see GHSA-727q-h8j2-6p45).

Description of developer facing changes:

N/A

Description of development approach:

• When creating a portable copy, do not pass parameters to the new instance. In any case, there is no UAC, so no risk of privilege escalation.
• Parameters are still being passed to the new instance during an update.
• When installing a new copy, I have kept parameters of original NVDA.

Testing strategy:

• portable creation: uses its own configuration
• portable update: uses the configuration of the previous portable, even, for example when using -c flag

Known issues with pull request:

None

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

@coderabbitai summary

[LeonarddeR]

What will happen with a portable copy that updates itself? I think it is desirable that in that case, the portable copy keeps the command line flags.

[CyrilleB79]

How can I perform test with an NVDA generated from a dev branch? The update mechanism is disabled in this case.

[SaschaCowley]

@CyrilleB79 You'll need to set updateVersionType to stable, snapshot:beta, or snapshot:alpha, and spoof the version to an updatable version.

• If you want to run from source, you can enable update check by changing updateVersionType in versionInfo.py (you need to do this in source because the update system isn't initialised otherwise). You will also need to spoof the version, which I find is most easily done by changing versionInfo.version from the NVDA Python Console before checking for an update.
• If you're happy building a launcher or portable, you can pass updateVersionType and version to scons dist or scons launcher.

[CyrilleB79]

OK I have finally been able to test portable update.

• I have compiled a launcher with:
  scons launcher version_build=30000 updateVersionType=beta -j8
• Then I have launched the launcher and created a portable from it.
• I have launched the just created portable normally and set its config (OneCore Hortense (French))
• I have then launched again the portable copy with an alternative config folder, using -c flag, and set a different config (OneCore Paul (French)).
• Then I have made the update (to 2025.2rc1)

I can confirm that during the update and after it when NVDA portable is relaunched, the alternative config folder (with Paul) is still being used, what is expected.

[seanbudd]

Thanks @CyrilleB79