Steps to reproduce:
- Press Windows+l to lock the computer.
- Press escape to dismiss the lock screen.
Actual behavior:
NVDA reports the Windows sign-in screen.
Expected behavior:
NVDA should first say "Secure Desktop" before reporting the sign-in screen.
System configuration
NVDA installed/portable/running from source:
Installed.
NVDA version:
2022.2.2
alpha-26424,2392d13c (2022.4.0.26424)
Windows version:
Windows 11 Version 21H2 (OS Build 22000.795)
Windows 10 Version 21H2 (OS Build 19044.1889)
Other Information
While this doesn't seem to matter on the surface, it causes a significant problem for NVDA Remote. Because of this, NVDA Remote doesn't know that the system has switched to a secure desktop when the lock screen is dismissed and so it doesn't react accordingly. That means that the user can't interact with the sign-in screen remotely, effectively locking them out of their system.
This issue was introduced in either 2022.2.1 or 2022.2.2. My guess is the former. I haven't dug into this much, but looking at the commit log, I'm guessing that IAccessibleHandler.SecureDesktopNVDAObject needs to be treated as secure or something like that.
Steps to reproduce:
Actual behavior:
NVDA reports the Windows sign-in screen.
Expected behavior:
NVDA should first say "Secure Desktop" before reporting the sign-in screen.
System configuration
NVDA installed/portable/running from source:
Installed.
NVDA version:
2022.2.2
alpha-26424,2392d13c (2022.4.0.26424)
Windows version:
Windows 11 Version 21H2 (OS Build 22000.795)
Windows 10 Version 21H2 (OS Build 19044.1889)
Other Information
While this doesn't seem to matter on the surface, it causes a significant problem for NVDA Remote. Because of this, NVDA Remote doesn't know that the system has switched to a secure desktop when the lock screen is dismissed and so it doesn't react accordingly. That means that the user can't interact with the sign-in screen remotely, effectively locking them out of their system.
This issue was introduced in either 2022.2.1 or 2022.2.2. My guess is the former. I haven't dug into this much, but looking at the commit log, I'm guessing that IAccessibleHandler.SecureDesktopNVDAObject needs to be treated as secure or something like that.