Created attachment 187873 [details]
stack of main thread

(hi James - i see this as a bug in LO but was thinking maybe it's a fun story)

The problem is that LibreOffice hangs indefinitely in a SendMessage call, only when NVDA is active.

This appears to be largely caused by LO's threading architecture, or lack thereof.

The problem depends on timing, and can be reproduced with the odk/examples/java/DocumentHandling/DocumentLoader.java program.

So there is an external process that starts LibreOffice and then communicates with it remotely via UNO.

The main difference to normal usage of LibreOffice is that this remote connection does its API calls on a thread which is not the main thread.

To make this work, there are several things where the non-main thread does a SendMessage to the main thread, as some things involving Win32 Windows have to be done on the main thread.  For example, there are custom messages sent to the main thread to create the HWNDs, DCs, etc.

Now at one point during loading a document, the Win32 function SetWindowTextW is called, which appears to be equivalent to a SendMessage(WM_SETTEXT) to the main thread. The code is here: https://git.libreoffice.org/core/+/refs/heads/master/vcl/win/window/salframe.cxx#1084

The problem is that this SetWindowTextW blocks forever; if replaced with the following it also blocks forever:
    SendMessageW(mhWnd, WM_SETTEXT, 0, reinterpret_cast<LPARAM>(o3tl::toW(rTitle.getStr())));

Meanwhile, the main thread blocks on a Win32 Event object (that is coupled with a global mutex), via MsgWaitForMultipleObjects and QS_SENDMESSAGE, calling PeekMessageW to dispatch anything sent via SendMessage.

The interesting difference with NVDA running is that while the WM_SETTEXT is being processed in DefWindowProcW, nvdaHelperRemote.dll functions are invoked, and calls oleacc.dll!AccessibleObjectFromEvent, and a WM_GETOBJECT message is dispatched to LO/VCL's handler.

Now handling the WM_GETOBJECT requires the same global mutex/Win32 Event thing that  the main thread is already blocking on, and this now blocks the handling of the WM_SETTEXT message further up the stack, so the non-main-thread that holds the global mutex is blocked on SendMessage forever.

My conclusion is that the main thread must process WM_GETOBJECT without ever acquiring the global mutex.