Consider not waiting for a reply in GenerateMouseEvent
Steps to reproduce:
- Get the mouse pointer's coordinates
- Use Orca to route the mouse pointer to the currently focused object.
- Get the mouse pointer's coordinates
The results I'm seeing are the following: The mouse pointer does successfully move, but only after a delay. There is also this error:
(orca:798897): dbind-WARNING **: 10:44:55.516: GenerateMouseEvent failed:
Did not receive a reply. Possible causes include: the remote application did not send a reply,
the message bus security policy blocked the reply, the reply timeout expired, or the network
connection was broken.
Orca is checking the mouse pointer's coordinates before the warning and the mouse movement and concluding things failed, when in reality they succeeded. Orca then reports the supposed failure to the user.
Would it be possible for this to not be a blocking call so that Orca could try to move the pointer and check immediately after if the pointer is at a new location?