Unexpected deactivation of screen curtain

[CyrilleB79]

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:

• The code architecture is complex and some bugs may be missed (e.g. this issue)
• The UX with screen curtain option (temporary vs permanent activation) is complex with regards to other options of NVDA
• In the case where profiles are used, privacy may be compromised. E.g: when the application (e.g. browser) tied to screen curtain is maximized in the background and another application not tied to screen curtain is in the foreground and does not cover the full screen.

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

• Find a solution with the current NVDA architecture
• Remove the relationship between profiles and screen curtain (see other open issues regarding screen curtain for discussions on this topic)

[feerrenrut]

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):

• Allow for multiple configs (profiles) to be edited simultaneously. So that a profile being modified by settings can be different from the active profile (which can be modified by gestures)
• Reflect changes to the config in the GUI when changed outside the GUI.

[seanbudd]

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]

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.