[Bug 43765] RSpec-Explorer windows are sometimes unresponsive to keyboard and mouse input

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=43765

--- Comment #2 from Zebediah Figura <z.figura12 at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.