Remote Access: prevent multiple disconnection confirmation dialogs

[cary-rowen]

Link to issue number:

None.

Summary of the issue:

In NVDA Remote Access, if a user is in "Follower" mode and the "Confirm disconnection when controlled" option is enabled, triggering the "Disconnect" action multiple times in rapid succession (e.g. by clicking the menu item repeatedly) results in multiple confirmation dialogs stacking on top of each other.

Description of user facing changes:

When attempting to disconnect from a Remote Access session, if a confirmation dialog is already open, NVDA will now focus the existing dialog instead of opening a new one.

Description of developer facing changes:

None.

Description of development approach:

The RemoteClient now maintains a reference to the active disconnection confirmation dialog in self._disconnectConfirmationDialog.
In doDisconnect, if this reference is set, the existing dialog is brought to the foreground. Otherwise, a new dialog is created, stored in the reference, and cleared in a finally block after it closes. This prevents re-entrancy while targeting only the specific dialog instance.

Testing strategy:

• Enabled "Confirm disconnection when controlled" in Remote Access settings.
• Triggered the "Disconnect" menu item repeatedly.
• Verified that only one dialog appeared and subsequent triggers focused the existing one.

Known issues with pull request:

None.

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

[cary-rowen]

I checked the failed jobs and they don't seem to be related to this change; it's a minor improvement.

[SaschaCowley]

I haven't looked at the code here, but based on the description, I think it might be better to keep a (weak) reference to the confirmation dialog, and bring it, specifically, to the foreground programmatically.
Consider what happens if the user performs the toggle connection/disconnect gesture, the confirmation dialog appears, and then another modal dialog is shown: with the current solution, the user must dismiss the new modal dialog before interacting with the disconnect dialog, even if they execute the toggle connection/disconnect command again.
Otherwise this is a good catch, thank you

[cary-rowen]

Hello @SaschaCowley
I agree with you. I've updated it; although there's a bit more code, I think it's worth it.