InputHint and WM_TAKE_FOCUS

[Tomas Carnecky]

Commit d836a5062141dd42293ed044debbaf25f914f383 broke sound in World of 
Warcraft. Yes, it sound strange but after I analyzed the issue it makes 
perfectly sense: a commit to dlls/winex11.drv/event.c broke sound.

According to the wine source and the ICCCM spec, wine uses either the 
'Passive' or 'Locally active' input model. InputHint is always set and 
WM_TAKE_FOCUS only if "UseTakeFocus" is set in the registry.
InputHint indicates that the window will have focus set by the WM, and 
WM_TAKE_FOCUS indicates that the app may set focus to it's own 
subwindows. Both metacity an compiz _don't_ send WM_TAKE_FOCUS to 
windows that have InputHint set!

The problem that arises from [1] is the following: If the WM calls 
XSetInputFocus() then the xserver sends a FocusIn event to the wine 
window, but wine ignores that event and waits for an WM_TAKE_FOCUS 
message. But that message never arrives because the WM never sends it. 
The above mentioned commit sets the foreground window to desktop if the 
WoW window looses focus. This makes WoW stop sound output. But the WoW 
window never regains focus and WoW won't resume sound output. I assume 
this bug has been in wine for a long time and even though it's a bug I 
enjoyed being able to switch away from WoW and still hear the sound 
(fishing/grinding while reading slashdot, hacking on wine etc).

The solution? Remove [1] (to process the FocusIn event) or remove 
InputHint from WM_HINTS. That would fix around the missing sound. 
Anyhow, 'sound while WoW lost focus' will be lost forever and I imagine 
there's no way to make that possible again but using a custom patch.

tom

[1]: http://source.winehq.org/source/dlls/winex11.drv/event.c#L509