`ui.message` fails to output braille when controlling a remote machine

[SaschaCowley]

Steps to reproduce:

1. Connect a braille display to the test computer.

2. Initiate a Remote Access connection, with the test computer as leader, and the other computer as follower.

3. Paste the following code snippet into the NVDA Python console:

   import wx, ui
   wx.CallLater(2000, ui.message, "Hello world!").Start()

4. Switch to controlling the remote computer (NVDA+alt+tab) (you need to do this within 2 seconds of issuing the above command. Adjust the delay if necessary).

5. Wait for ui.message to be called.

Actual behavior:

NVDA speaks "Hello world!", but nothing is brailled.

Expected behavior:

"Hello world!" should be both spoken and brailled.

NVDA logs, crash dumps and other attachments:

IO - speech.speech.speak (15:35:42.729) - MainThread (22204):
Speaking ['Log fragment start position marked, press again to copy to clipboard']
IO - braille.BrailleBuffer.update (15:35:42.729) - MainThread (22204):
Braille regions text: ['Log fragment start position marked, press again to copy to clipboard']
IO - braille.BrailleHandler.update (15:35:42.729) - MainThread (22204):
Braille window dots: 6 123 135 1245 - 124 1235 1 1245 56 2345 - 34 345 2345 - 1234 135 234 24 56 1345 - 134 345 13 1246 2 - 1234 1235 15 234 234 - 1 1245 - - -
IO - inputCore.InputManager.executeGesture (15:35:44.576) - winInputHook (11012):
Input: kb(laptop):upArrow
DEBUG - editableText.EditableText._hasCaretMoved (15:35:44.594) - MainThread (22204):
Caret move detected using event. Elapsed 0 sec, retries 0
IO - speech.speech.speak (15:35:44.597) - MainThread (22204):
Speaking ['wx.CallLater(2000, ui.message, "Hello world!").Start()']
IO - braille.BrailleBuffer.update (15:35:44.597) - MainThread (22204):
Braille regions text: ['NVDA Python Console ', '>>> edt ', 'wx.CallLater(2000, ui.message, "Hello world!").Start() ']
IO - braille.BrailleHandler.update (15:35:44.600) - MainThread (22204):
Braille window dots: 236 6 125 15 123 123 135 - 456 2456 235 6 2356 5 345 256 6 34 345 2345 5 126 5 345 - - - - - - - - - - - - - - - -
IO - braille.BrailleBuffer.update (15:35:44.602) - MainThread (22204):
Braille regions text: ['NVDA Python Console ', '>>> edt ', 'wx.CallLater(2000, ui.message, "Hello world!").Start() ']
IO - braille.BrailleHandler.update (15:35:44.602) - MainThread (22204):
Braille window dots: 236 6 125 15 123 123 135 - 456 2456 235 6 2356 5 345 256 6 34 345 2345 5 126 5 345 - - - - - - - - - - - - - - - -
IO - inputCore.InputManager.executeGesture (15:35:45.989) - winInputHook (11012):
Input: kb(laptop):enter
IO - speech.speech.speak (15:35:46.007) - MainThread (22204):
Speaking ['>>>']
IO - braille.BrailleBuffer.update (15:35:46.018) - MainThread (22204):
Braille regions text: ['NVDA Python Console ', '>>> edt ', ' ']
IO - braille.BrailleHandler.update (15:35:46.018) - MainThread (22204):
Braille window dots: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IO - inputCore.InputManager.executeGesture (15:35:46.582) - winInputHook (11012):
Input: kb(laptop):NVDA+alt+tab
INFO - _remoteClient.client.RemoteClient.toggleRemoteKeyControl (15:35:46.587) - MainThread (22204):
Remote key control enabled
IO - speech.speech.speak (15:35:46.587) - MainThread (22204):
Speaking ['Controlling remote computer']
IO - speech.speech.speak (15:35:47.999) - MainThread (22204):
Speaking ['Hello world!']
INFO - _remoteClient.client.RemoteClient.toggleRemoteKeyControl (15:35:49.707) - MainThread (22204):
Remote key control disabled
IO - speech.speech.speak (15:35:49.707) - MainThread (22204):
Speaking ['Controlling local computer']
IO - braille.BrailleBuffer.update (15:35:49.707) - MainThread (22204):
Braille regions text: ['Controlling local computer']
IO - braille.BrailleHandler.update (15:35:49.707) - MainThread (22204):
Braille window dots: 6 25 2345 1235 135 123 123 346 - 123 135 14 1 123 - 14 135 134 1234 136 2345 12456 - - - - - - - - - - - - - - - - - -
IO - inputCore.InputManager.executeGesture (15:35:53.447) - winInputHook (11012):
Input: kb(laptop):NVDA+control+shift+f1

Technical cause

This happens because _remoteClient.localMachine.LocalMachine registers a braille.decide_enabled handler which returns True when controlling the local computer, and False when controlling the remote computer. RA can then use braille.handler._writeCells to write braille display contents received from the remote machine directly to the braille display. The (usually desired) side effect is that the local NVDA doesn't change the contents of the braille display, unless RA tells it to.

System configuration

NVDA installed/portable/running from source:

Tested with installed and running from source

NVDA version:

alpha-36145,439adf19 (2025.2.0.36145)

Windows version:

24H2 (OS Build 26100.3775)

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

None

Other information about your system:

Tested with a Hims Brailleedge40, though the particular braille display in use does not make a difference.

Other questions

Does the issue still occur after restarting your computer?

Yes

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

No

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?

Yes

[SaschaCowley]

I've tried just setting _remoteClient._remoteClient.localMachine.receivingBraille to False, issuing the ui.message, then switching it back, but this has the undesirable effect of causing the display to show the last contents of the local buffer after the message disappears. I also think it may cause other problems, like not being able to be manually dismissed.

[SaschaCowley]

@LeonarddeR do you have any ideas on how we could resolve this?

[LeonarddeR]

This was by design initially. When you are controlling the remote machine, your braille input and output is entirely bound to that remote machine. Therefore, brailing an ui.message from the local machine would not only cause confusion about the source of the Braille, it would also cause ambiguity about where braille display gestures have to go when the message is displayed.
I agree that a similar ambiguity exists with speech, though.

note that when remote braille is enabled, the local braille handler is completely suppressed and disabled anyway. Revamping this would be a partial rewrite of the remote braille system. That said, now remote is in core, that should be a lot easier. For example, rather than suppressing the local braille handler, we could consider adding a new RemoteBrailleBuffer and set that as the main buffer when the remote system outputs braille. Gestures should go to the remote system when the remote buffer is the main buffer. When a local message come in, it will temporarily set the MessageBuffer as the main buffer but can easily return to the RemoteBuffer after the message is dismissed.