Support Ease of Access

[nvaccessAuto]

Reported by jteh on 2009-04-24 01:58
NVDA can currently only run on the user input desktop on which it was started. It cannot switch to secure input desktops, which is required for UAC screens and the Windows logon screen. For Windows Vista and later, the Ease of Access framework is used to launch ATs on other input desktops. NVDA should support Ease of Access.
Blocked by #5037
Blocking #100, #3854, #4158

[nvaccessAuto]

Comment 2 by jteh on 2009-05-18 01:07
The service for Windows XP works very well on Windows Vista and Windows 7. In addition, there are some issues blocking the implementation of useable support for EoA. We'll just use the service on Vista and Windows 7 unless there is a good reason to support EoA. Closing as wontfix for now; reopen later if the situation changes.
Changes:
Added labels: wontfix
State: closed

[nvaccessAuto]

Comment 4 by jteh on 2014-01-19 15:05
There are now a few good reasons to register with Ease of Access:

• Windows 8 and 8.1 intentionally delay all desktop apps set to start automatically by several seconds. This can be reduced somewhat with a registry tweak, but not entirely, and we shouldn't make changes that affect things other than NVDA anyway.
• ATs need to be registered with EoA in order to be candidates for activation with Windows+volumeUp.
• Aside from these, it's probably more future proof to do this and it means we don't have a background service running (no matter how light) even when NVDA isn't.

Windows 8 introduced changes to Ease of Access that make it quite usable for us. Specifically, you can now specify that an AT shouldn't be terminated on a desktop switch, which is exactly what we need.

The question is whether to do this for Windows Vista and 7 as well. Termination on desktop switch is annoying, but I've managed to come up with a convoluted way to work around that, though it does require another executable to be running while NVDA is running.
Changes:
Removed labels: wontfix
State: reopened

[nvaccessAuto]

Comment 6 by James Teh <jamie@... on 2014-01-22 06:10
In [fa75c1f]:

Merge branch 't308' into next

Incubates #308.

Changes:
Added labels: incubating

[nvaccessAuto]

Comment 8 by James Teh <jamie@... on 2014-01-29 08:45
In [9901467]:

Merge branch 't308' into next

Incubates #308.

[nvaccessAuto]

Comment 9 by James Teh <jamie@... on 2014-01-30 06:03
In [ab34b09]:

Merge branch 't308' into next

Incubates #308.

[nvaccessAuto]

Comment 10 by James Teh <jamie@... on 2014-01-30 07:52
In [84a9a74]:

Merge branch 't308' into next

Incubates #308.

[nvaccessAuto]

Comment 11 by James Teh <jamie@... on 2014-01-31 04:40
In [53050d1]:

Merge branch 't308' into next

Incubates #308. I'll get this right eventually.

[nvaccessAuto]

Comment 12 by driemer.riemer@... on 2014-02-01 07:08
I think this would be better to list under features, rather than bugs.

1. It is listed as an enhancement rather than a defect.
2. It isn't something being fixed, rather something being added to nvda that speeds it up at start up.

I am not an expert on this though, so feel free to tell me if there are specific reasons it is listed as a bug fix.
Thanks,
Derek

[nvaccessAuto]

Comment 14 by jteh on 2014-05-01 00:23
Changes:
Milestone changed from None to next

[nvaccessAuto]

Comment 15 by blindbhavya on 2014-10-02 10:04
Hi.
I was wondering...
The status of this ticket is Incubating for months now.
IF the patch is good enough, I think the status should be made Fixed and Milestone 2014.4
Do correct me if I have missed anything.

[nvaccessAuto]

Comment 17 by jteh (in reply to comment 12) on 2014-10-07 23:11
Replying to driemer.riemer@…:

I think this would be better to list under features, rather than bugs.

1. It is listed as an enhancement rather than a defect.

That's true as far as the code is concerned. However, from a user perspective, it fixes a bug which is that NVDA is slower to start automatically on Windows 8.1. Normally, the two audiences match, but in this case, they don't.

1. It isn't something being fixed, rather something being added to nvda that speeds it up at start up.

Again, think about the user perspective. The user doesn't think of it as a feature, even though it's a significant code refactor.

[nvaccessAuto]

Comment 18 by jteh (in reply to comment 15) on 2014-10-07 23:15
Replying to blindbhavya:

The status of this ticket is Incubating for months now.

IF the patch is good enough, I think the status should be made Fixed and Milestone 2014.4

It's not good enough yet. It works, but the problem is that if you downgrade to an older version of NVDA, you'll end up with some serious issues such as NVDA not running in secure mode on secure desktops. This is because the installer for the old version doesn't know about Ease of Access. The solution is probably to make the installer use the older uninstaller, but that will only work for versions where that is implemented. For example, if we implement that for 2014.4, downgrading to 2014.3 will still break. There isn't really a good solution for this, but we should at least try to not break when downgrading to the previous version, which means making this change and then waiting one more release before we merge Ease of Access.

[nvaccessAuto]

Comment 20 by leonarddr (in reply to comment 18) on 2015-02-03 10:17
Replying to jteh:

There isn't really a good solution for this, but we should at least try to not break when downgrading to the previous version, which means making this change and then waiting one more release before we merge Ease of Access.

Is it really necessary to take care of people downgrading to older versions of NVDA? The only downgrading i've ever done is from a development branch to a stable branch. Also, older versions aren't easy to find on the NV Access website, so people would only downgrade to locally saved older versions or search in the sourceforge archives. People thus experienced wouldn't have any problem with applying some tweaks before downgrading. I'd say mentioning the downgrading issues in the release announcement would be enough.
If not, though, may be the installers recognision of ease of access could be implemented in 2015.2 so 2015.3 could be the milestone of this ticket?

[nvaccessAuto]

Comment 21 by jteh on 2015-04-14 07:02
The plan is:

1. For downgrades, make the installer unregister the installation using the previous copy. This should be done for 2015.3 (it's too late for 2015.2). See Installer should warn about downgrades #5037.
2. Because this could be a major security hazard, implement a new command line option (--eoa) which is only called when running from Ease of Access. This will cause older versions of NVDA to fail to start with an error. This is ugly, but it's much better than a security hazard.
3. Finally, get Ease of Access support into NVDA 2015.4. That at least means anyone downgrading to 2015.3 (the version before, which is most likely if any downgrading does occur) won't get bitten by the ugliness in (2).

[nvaccessAuto]

Comment 22 by jteh on 2015-04-14 07:03
Changes:
Milestone changed from next to 2015.4

[nvaccessAuto]

Comment 23 by leonarddr on 2015-04-14 07:17
Please note that, when #3724 will be ready to go in master, easeOfAccess can make use of winVersion.winVersion instead of retrieving it from sys

[nvaccessAuto]

Comment 24 by leonarddr (in reply to comment 23) on 2015-08-18 12:10
Replying to leonarddr:

Please note that, when #3724 will be ready to go in master, easeOfAccess can make use of winVersion.winVersion instead of retrieving it from sys

Please see the attached patch for this

[nvaccessAuto]

Attachment eof_winversion.patch added by leonarddr on 2015-08-18 12:11
Description:
EOF code now uses WinVersion.winVersion rather than retrieving it from sys

[nvaccessAuto]

Comment 25 by James Teh <jamie@... on 2015-09-16 23:17
In commit 75d5ddf:
Use Ease of Access in Windows Vista and later.

The primary motivation for this is that NVDA starts a lot earlier after logging on in Windows 8 and later. However, it should also be more reliable and future proof than using our own service. Also, this means NVDA is now listed in the Ease of Access Center on Windows 8 and later.

Note that in Windows Vista and 7, Ease of Access can't be instructed not to terminate ATs on every desktop switch, so we use a proxy process. Unfortunately, Windows also terminates child processes, so we can't use EoA to start NVDA on non-secure desktops at all. Because of this, we don't show it to the user in the EoA Center at all.

Some other noteworthy changes that were needed:

• Rather than specifying command line options from the service when starting NVDA on the secure desktop, make NVDA itself detect this and set the appropriate options. This is needed for Ease of Access, where there is no elegant way to pass different options for secure desktops.
• Use the name of the input desktop for the main thread instead of the current input desktop for the startup mutex. This is particularly important because EoA can sometimes start NVDA on the default desktop before switching to it.
• When NVDA has uiAccess, don't show and hide our window on startup, as this messes with the focus and causes focus to be moved out of the Start Screen in Windows 8/8.1. uiAccess allows us to always come to the foreground anyway.

Fixes #308.
Changes:
Removed labels: incubating
State: closed