nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.1k stars 636 forks source link

Unexpected deactivation of screen curtain #14121

Open CyrilleB79 opened 2 years ago

CyrilleB79 commented 2 years ago

Steps to reproduce:

  1. Associate a gesture for screen curtain activation.
  2. Open Windows Explorer
  3. Open Notepad
  4. Create a profile for Notepad
  5. Alt+Tab to Notepad
  6. Open NVDA settings, e.g. Speech settings (NVDA+ctrl+V)
  7. Alt+Tab to Windows Explorer without closing the settings window.
  8. Activate the screen curtain with its associated gesture.
  9. Open another settings panel, e.g. General settings (NVDA+ctrl+G)
  10. Discard the setting window with escape.

Actual behavior:

Discard the setting window with escape.

Screen curtain is deactivated.

Expected behavior:

Discard the setting window with escape.

Screen curtain should remain activated.

NVDA logs, crash dumps and other attachments:

nvda_screenCurtainDeactivation.log (steps 2 to 7)

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2022.3beta4

Windows version:

10

Name and version of other software in use when reproducing the issue:

N/A

Other information about your system:

N/A

Other questions

Does the issue still occur after restarting your computer?

Not yet tested, probably yes.

Have you tried any other versions of NVDA? If so, please report their behaviors.

Not tested. Probably occurs on earlier versions of NVDA.

If NVDA add-ons are disabled, is your problem still occurring?

Yes

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

Not tested. Probably nothing to do with this issue.

Note

As I have already written in other open issues related to screen curtain, I think that screen curtain as implemented in NVDA (activated by profiles, temporary vs permanent) poses a risk regarding privacy:

Thus for the resolution of this issue there are two options:

feerrenrut commented 2 years ago

In the short-term (due to lower implementation time cost) I'd opt for making screen curtain always apply generally (I.E never profile specific). But we'll need to consider the implications of this on users who are currently relying on screen curtain configured for certain profiles. They may need to be warned in some way that the behavior has changed.

I suspect the underlying cause in this case is that the gesture allows changing a config value that has already been read by the settings GUI, then the GUI overrides the value on exit.

Note: the active profile doesn't seem to change when a settings dialog is open, even if the focused app is changed.

In the longer term (this might be what you mean by architecture complexity):

seanbudd commented 6 months ago

One solution not mentioned here is not allowing commands that change settings to be used while the settings dialog is open. This could be fixed by creating a new gui.blockAction.Context.

As mentioned earlier an alternative is to make screen curtain no longer profile dependent. This could be done by removing it from the settings panel, and making it only context specific when using the command to activate it. A new setting "start NVDA with screen curtain enabled" might cover the general use case of wanting screen curtain always enabled.

As mentioned in https://github.com/nvaccess/nvda/issues/14121#issuecomment-1247715656 this change of behaviour is quite serious and would need to be discussed.

Further feedback on how to best approach this issue is encouraged.

CyrilleB79 commented 6 months ago

One solution not mentioned here is not allowing commands that change settings to be used while the settings dialog is open. This could be fixed by creating a new gui.blockAction.Context.

IMO blocking the setting change commands while in setting dialog could be frustrating for users, especially for synth setting ring commans and audio commands (e.g. audio ducking). And blocking only a subset of them would just make the user experience more complex.

As mentioned earlier an alternative is to make screen curtain no longer profile dependent. This could be done by removing it from the settings panel, and making it only context specific when using the command to activate it. A new setting "start NVDA with screen curtain enabled" might cover the general use case of wanting screen curtain always enabled.

I agree with this proposal, also because as of today, no use case has been exhibited in the various related issues for a profile-based screen curtain usage which would fully guarantee the privacy.

As mentioned in #14121 (comment) this change of behaviour is quite serious and would need to be discussed.

This may be technically difficult to address since we have not yet any cross-profile config update mechanism. But the best solution to update the config files would be to enable screen curtain at NVDA startup if any of the profiles (including base one) has screen curtain enabled.