[Bug 43765] New: RSpec-Explorer windows are sometimes unresponsive to keyboard and mouse input
https://bugs.winehq.org/show_bug.cgi?id=43765
Bug ID: 43765 Summary: RSpec-Explorer windows are sometimes unresponsive to keyboard and mouse input Product: Wine Version: 2.17 Hardware: x86 URL: https://www.rspec-astro.com/setupdownload/ OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: z.figura12@gmail.com Distribution: ---
Under some conditions, the application will refuse to respond to mouse and keyboard input. The windows can be minimized, closed, focused, etc; and edit controls will blink the caret, but buttons won't be clicked and other controls similarly won't update. This affects not only the main window but also the common open-file dialog.
I can pretty reliably trigger this by starting the main application, ensuring that it is not maximized, then clicking the folder icon in the upper left to trigger the open-file dialog. Said dialog will in most cases not respond to input as described above; and, when it is closed, the main window will sometimes similarly stop responding to input. I can also see this behaviour, though less consistently, with the first window that shows up (warning you that this program is a free trial); this window sometimes fails to respond to input, and usually the main window will fail to respond after it is closed.
This state of unresponsiveness can in fact be undone. If the main window is unresponsive, minimizing and restoring it will cause it to again be responsive. More bizarrely, if one of the dialog windows is unresponsive, moving the main window below the dialog (or nearly below it) will cause it to be responsive; additionally, any keyboard or mouse events will be processed.
Adding some traces to DIALOG_DoDialogBox() shows that there are clearly mouse events in the queue, but they seem to be ignored by PeekMessage(). I have no idea why this would happen.
https://bugs.winehq.org/show_bug.cgi?id=43765
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
https://bugs.winehq.org/show_bug.cgi?id=43765
--- Comment #1 from Zebediah Figura z.figura12@gmail.com --- More information:
- I seem to be able to avoid most unresponsiveness by having the main window maximized. - Selecting the "Live Camera" button in the lower left seems to consistently cause unresponsiveness in the main window, sometimes even when maximized. The window also appears to prevent itself from being minimized or closed while this occurs, so this state of unresponsiveness cannot be similarly undone and the application must in fact be killed. - I have also noticed frequent page faults or stack overflows occurring from selecting this tab (and, on occasion, from simply opening the main window); these seem to consistently cause secondary crashes in winedbg as well.
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.
https://bugs.winehq.org/show_bug.cgi?id=43765
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- Created attachment 59319 --> https://bugs.winehq.org/attachment.cgi?id=59319 hack to prevent infinite loop in video window thread
https://bugs.winehq.org/show_bug.cgi?id=43765
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |quartz Summary|RSpec-Explorer windows are |RSpec-Explorer windows are |sometimes unresponsive to |sometimes unresponsive to |keyboard and mouse input |keyboard and mouse input | |(VideoWindow should not be | |run in separate thread)
--- Comment #4 from Zebediah Figura z.figura12@gmail.com ---
From the docs:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd407349(v=vs.85).a...
"Normally, this filter's video window processes messages on a worker thread created by the Filter Graph Manager. Howerver, if an application directly creates the filter using CoCreateInstance, the video window processes messages on the application thread. In that case, the application thread must have a message loop, to dispatch messages to the video window. Also, the thread must not exit until the final Release call to the Video Renderer, which occurs when the Filter Graph Manager shuts down. Otherwise, the application might deadlock."
The application creates the VideoRenderer instance manually, but we don't handle that case and create a separate thread anyway.
https://bugs.winehq.org/show_bug.cgi?id=43765
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|RSpec-Explorer windows are |RSpec-Explorer windows are |sometimes unresponsive to |sometimes unresponsive to |keyboard and mouse input |keyboard and mouse input |(VideoWindow should not be | |run in separate thread) |
--- Comment #5 from Zebediah Figura z.figura12@gmail.com --- Removing diagnosis; I'm not sure it's correct. This needs more tests.
https://bugs.winehq.org/show_bug.cgi?id=43765
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #6 from Zebediah Figura z.figura12@gmail.com --- This doesn't happen anymore. It was probably fixed by changes to quartz windowing/threading.
https://bugs.winehq.org/show_bug.cgi?id=43765
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.8.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla