Add-on store: don't interrupt user for addon install tasks when exiting.

[feerrenrut]

Is your feature request related to a problem? Please describe.

See prototype add-on store at: #13985
Installing an addon has the following workflow:

• When installing an add-on, the add-on is downloaded in the background.
• The user is able to continue browsing add-ons, and even queue further add-ons for download / installation.
• When the user attempts to exit the add-on store, the add-ons are installed.
• At this point the install tasks for add-ons are run. The user must interact with any prompts that add-ons raise before being able to continue with their next task. This delays the user; they can't continue to an urgent task. It reduces user autonomy; they are no longer in control of when the (potentially very many) install tasks take place.
• Then the user is prompted to restart NVDA.

Note:

• A user can select many add-ons to download and install.
• Installing updates will exacerbate this issue, being able to postpone install tasks to reduce interruptions will be beneficial.
• NVDA may support auto-installing add-ons based on a config file in the future, another case that would exacerbate the issue.

Describe the solution you'd like

The user experience could be improved if add-ons were installed (and the add-on install task ran) when NVDA next restarts.

• This allows the add-ons to be "installed" in the background when exiting the add-on store dialog.
• The user will still be prompted to restart NVDA, however if they have an urgent task, they can select later.

There is a risk this may break assumptions by add-on authors, so will considered a compatibility breaking change.
This will need to be scheduled for a compatibility breaking release.

Describe alternatives you've considered

Apart from leaving the current workflow for add-on install tasks, another option is to run the installation and install tasks as soon as each add-on is downloaded. However, this results in many interruptions (for the add-on install task GUI prompts) with unknown timing between them. Batching the install tasks together is a smoother user experience.

Additional context

This issue is intended to outline the rational on the for this on the PR #139854 and was requested in:
#13985 (comment)

From the discussion on the PR it seems you're planning to make the install tasks execute after NVDA is restarted, rather than, as it is now, during the add-on install. This is going to make most usages of install tasks pretty difficult and make them much less useful. I don't want to go into specific examples here to avoid getting off topic, and also because you gave no reasoning for the change, so it is hard to discuss pros and cons. Could you create a separate issue / discussion outlining what, exactly, you intend to modify and why, so that add-on and core developers can be informed in advance and check if this is going to meet their needs?

[lukaszgo1]

My apologies for not commenting here earlier, even though I was the one whose question triggered this issue on the add-on store PR.
In general this change is going to be pretty painful, and the problem outlined in the initial comment should be solved differently - more on that below.
To start I am going to list some use cases for the current install tasks (the list won't be exhaustive, as I've only looked at the add-ons I have installed), to make sure we are on the same page, as it looks like neither Reef Turner nor @seanbudd have done so before checking if what has been proposed here is the best possible strategy:

• Migration of files from the previous version of the add-on to the new folder. moving install tasks and installation in general until after the restart would work in this case with some caveats. There still would be a change in behavior here, since the old add-on folder would be removed not after the restart (that cannot be done since we need access to it), but after the next restart. Care would need to be taken not to load add-on from this folder, but also to make sure that if installation of the new add-on fails for any reason the old version of the add-on is not mistakenly removed.
• Showing an arbitrary GUI prompt. This can be anything from letting user know about some important functionality of the add-on before installation, requesting donation, letting user know that the format of the add-on config has changed and user has to configure it from scratch, to asking if NVDA's config can be changed for better operation of the add-on (report passwords does something like this). To make this use case possible NVDA has to be fully initialized (GUI, speech, Braille) so that would be quite a change as add-ons are loaded way earlier at present. This also raises some usability concerns for people who use synthesizer and Braille display drivers packaged as add-on. When updating such add-on the old version of they driver cannot be loaded since it is pending uninstallation, the new version cannot be loaded either since it is not installed yet. Such user is left with a default speech synthesizer in this session of NVDA, and in case of a Deafblind users without access to their Braille display. There is also, once again, an issue of reverting the uninstalled add-on if install tasks failed for whatever reason.
• Some add-ons uninstall (either asking before doing so, or forcefully) other add-ons from NVDA in case of known incompatibilities between them, or perhaps (one of my add-ons is in this category) due to the fact that functionality of two add-ons has been merged into one. In this specific case executing install tasks before restart ensures that the old, conflicting add-on, would not be loaded when the new add-on is installed. I see no way to enforce this when install tasks are executed after restart, except forcing yet another restart of NVDA after all add-ons are installed which is, IMHO, pretty ugly.
• Some add-ons verify compatibility as part of the install tasks, and allow to continue the installation only if whatever they check for (be it minimum Windows version, or presence of a touch screen) exists. In that case the change in ordering means that user has to restart NVDA, only to learn that the add-on they're installing cannot be installed. I have never encountered an installer which verifies compatibility with something after forcing user to restart ,as restarting is quite disruptive process.

There is also an assumption in the initial description that install tasks are disruptive, and disallow user to continue whatever they were doing. This is not true in general - most of them are either non interactive, or show a prompt only in very specific cases i.e. incompatible add-ons installed or change of a config format.

It looks like the initial problem from this issue can be stated as follows:

When user closes add-ons store having installed one or more add-ons, we want to make sure they are not forced to work through prompts shown as a result of install tasks immediately, as they may want to continue to an urgent task.

Assuming this is correct, I propose to add an option to postpone installing add-ons, similarly to what we have for downloaded updates. I imagine that when user closes add-on store they're presented with a prompt which asks if they want to install add-on now, or later. If they choose 'now' add-ons are installed, and NVDA restarts. When 'later' is selected there should be an additional control in the add-on store, which, when activated, executes installations. Obviously #15613 has to be fixed in that case.
@seanbudd Would the proposed implementation be acceptable for NV Access? If it is not acceptable why?

[XLTechie]

I have been wondering for a while, if we need some more package management functions. * pre_update(): is called before the deletion of the old add-on directory. * post_update(): is called before the newly installed add-on version is run for the first time, so after the restart. I am envisioning that pre_update() can move add-on config files to a holding folder under %temp% or even in NVDADir/tmp, or whatever. Then post_update() can move them back into the new add-on directory, perform upgrade of configs, etc. (For add-ons which need this sort of thing) Naturally, this would require keeping track of which add-ons are in new install pending vs. update install pending, status. I admit I have not had time to think through all possible implications, but I borrowed the pattern from the Debian package manager's (dpkg) preinst, postinst, prerm, etc. stack.

[lukaszgo1]

@XLTechie I have trouble understanding how these proposed hooks would help with this issue, especially with use cases 2-4 of my above comment. I'm by no means saying that new hooks are not necessary or anything, just that if you have a specific use case in mint they probably should be discussed in a separate issue.

[lukaszgo1]

@michaelDCurran @seanbudd Can we please have a comment from NV Access with regard to your plan here? One of my add-ons which I want to have ready for the store in time for 2024.1 is affected by #15613, but I'm reluctant to work on a fix without knowing how you want to progress with the current issue, as that is a prerequisite for any work on #15613.

[seanbudd]

I imagine that when user closes add-on store they're presented with a prompt which asks if they want to install add-on now, or later. If they choose 'now' add-ons are installed, and NVDA restarts. When 'later' is selected there should be an additional control in the add-on store, which, when activated, executes installations. Obviously #15613 has to be fixed in that case.
@seanbudd Would the proposed implementation be acceptable for NV Access? If it is not acceptable why?

I think due to the synth/braille issue something like this is a good alternative. However, I would make it as a blocking modal dialog which presents the option "Finalize add-on installations now" only. This allows the user to perform tasks before triggering the install tasks, but blocks other NVDA GUI interactions like exiting NVDA.

Additionally, I think we still need to expand the API here (in a non-breaking way):

• To fix Addon store restart dialog is overlaping installtasks dialog #15613 we still need something is needed to track when blocking install tasks are in progress. This might require authors notifying the API manually when a task starts and completes. I'm hoping we can avoid this by wrapping install tasks. When all install tasks are done, we prompt the user to restart NVDA.
• Install tasks which can be postponed to when the add-on is actually installed during the next NVDA restart should have the option to do so. I think we should split the concept into (pre-)install tasks (before restart) and post-install tasks (after restart, when the add-on is actually installed). This can be done with a postInstall installTasks module

[seanbudd]

This is being removed from the milestone as this should no longer require a breaking change, and has minimal user impact. It is just the option to delay starting install tasks after closing the add-on store, and potentially adding a new API for post-install tasks.

#15613 can be fixed independently to this by tracking on-going install tasks

[lukaszgo1]

I think due to the synth/braille issue something like this is a good alternative. However, I would make it as a blocking modal dialog which presents the option "Finalize add-on installations now" only. This allows the user to perform tasks before triggering the install tasks, but blocks other NVDA GUI interactions like exiting NVDA.

It looks like I misunderstood the original intent of this issue. After reading the initial comment I imagined the following sample scenario:

1. User installs some add-ons
2. They receive a notification about something important to do, perhaps via phone, or email notification
3. Since it is impossible to say what action they need to take, any limitation imposed on them is potentially annoying, so we want to allow them to close the store, and do whatever they need

With the design I proposed i.e. giving ability to delay add-on installs to some, unspecified point in time, they can for example restart their machine if that is necessary, and return to the add-on installs at some, more convenient time. In general since we offer that kind of flexibility for NVDA updates I see no reason not to do so for add-on installs. This can become more relevant when auto updates for add-ons is added into core, as time at which auto updater shows installation message is unpredictable.

Install tasks which can be postponed to when the add-on is actually installed during the next NVDA restart should have the option to do so. I think we should split the concept into (pre-)install tasks (before restart) and post-install tasks (after restart, when the add-on is actually installed). This can be done with a postInstall installTasks module

In terms of implementations that is easy, documenting when to use which one is going to be pretty tough, though and list of use cases for which post-install tasks would be sufficient is quite limited. In general it would work only for add-ons which do not need to present any GUI to the user when installing, do not care about being backwards compatible, and do not need access to the previous add-on folder, as the old version would be uninstalled at this point. I'm not sure if that is worth the effort.