Workaround fix - NVDA starts after logon even when this is disabled (Win 10 1903)
toggle quoted messageShow quoted text
If NVDA starts after logon even if disabled following Win 10 1903 update, here is a work around script :
This script needs to be copied in the scratchpad\globalPlugins directory after having active the scratchpad option (if required).
This script does not fixes the issue but unloads NVDA if it was not configured to start after logon.
Feedback welcomed although it is a “quick dirty script”.
I do not plan to release it as an addon, unless there is a demand.
De : email@example.com <firstname.lastname@example.org> De la part de Cyrille via Groups.Io
Reading the ticket, I have understood that :
Thank you for this information, that you also wrote in the ticket.
Since the fix will not be provided by MS before 2020, I intend to develop this workaround so that my wife does not have to quit NVDA (or forget to do it) each time she starts her session.
Seems that I still just need to figure if current NVDA version was run with the --ease-of-access flag. Is there an internal variable for it ? Or should I deal with NVDA process command line ?
Hi. My copy of NVDA running on Windows 10 1903 is not subject to this fault. It might be that I have Jaws running as the default startup screen reader, but as of now, NVDA will not start on my desktop unless I explicitly tell it to do so with the usual alt+ctrl+n. Cheers!
On 8/19/2019 11:22 PM, Joseph Lee wrote:
Hi Cyrilletoggle quoted messageShow quoted text
Tested and confirmed to work properly *on my system* in NVDA 2019.2 beta.
But note, that is only properly on my own system. See below for why that may not always be true, and why this is probably a bad idea.
First, a couple thoughts:
I very strongly suggest that you have this log something at info level about what it's doing. At the moment, there is no evidence in the log that it even exists, and I consider that a major bug.
Furthermore, I wonder if you could get it to run sooner, by renaming it with a name that sorts first in the add-on load process ("000startupOptionWorkaround.py", for example), and packaging it as an add-on, even for your own use, so it is not subject to scratchpad loading, which appears to be a late load.
Now, all of that said:
Joseph Lee and I talked about this back in July, and he convinced me that doing it via globalPlugin was a bad idea. The best method would be to do it in core, right after config data is read in, but before anything really important happens.
Here was his reasoning (posted with permission):
As for an add-on solution, very risky. Imagine an add-on that loads before
this one and performs something users may need to know, and then the
proposed add-on comes in and closes NVDA if NVDA is told to not start for
this user. If the previous add-on was holding onto a resource that isn't
cleaned up properly, that'll result in leaks. Or imagine an add-on that was
previously loaded that somehow patches the shutdown routine. If that
happens, NVDA will get confused when the proposed add-on unexpectedly
On Tue, 20 Aug 2019, Cyrille via Groups.Io wrote: