https://bugs.winehq.org/show_bug.cgi?id=43765
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- After delving somewhat deep into the message code, I have managed to discover the problem.
The application creates a CLSID_VideoRenderer on a separate thread, queries it for IVideoWindow, then sets the parent window to one of its own windows. The video window then receives a WM_SETCURSOR message, passes it along to DefWindowProc, which, because it's a child window, sends the message to the parent. However, the parent's window procedure, for whatever reason, posts the same WM_SETCURSOR message back into the child window. This causes the thread to spinloop infinitely, since every time it processes a WM_SETCURSOR message, one gets posted back into the queue.
Meanwhile, on the main thread, the user opens a dialog (which could be the file selection dialog or a different dialog; it doesn't matter). The user moves the mouse, generating an event which X thinks belongs to the application window (or some window on the main thread) but which Wine determines belongs to the video window and therefore need to be processed by that thread.
We get stuck, then, in the following situation:
* The user generates hardware events on the dialog window (or on the main window) which accordingly get queued into the main thread. However, they can't be processed yet, because they're stuck behind the aforementioned WM_MOUSEMOVE message, which is sitting in the main thread's message queue but needs to be processed by the video window's thread.
* The video window's thread is running a message loop and should in theory be taking care of processing this message. However, the message queue is receiving posted messages exactly as fast as they're being processed, so every call to GetMessage() will return a WM_SETCURSOR message, so any hardware messages will never be processed.
If we hack the video window's window procedure not to call DefWindowProc() on receiving a WM_SETCURSOR, then we can remove the infinite loop and prevent this bug. Figuring out the correct solution, however, seems much harder.