[Bug 48121] Unity games do not fire OnApplicationFocus/OnApplicationPause events on focus regain

[WineHQ Bugzilla]

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

--- Comment #14 from w at zeroitlab.com ---
> Well sure it's old but it's also been there for a while, not breaking other apps, and probably serves a purpose.
Well, now it does break Unity apps so there's that

> Maybe Windows doesn't let the application decide if it should be activated or not when Alt-Tab is used, but maybe it does when clicking on it.
This is 100% true.

> The code covers the former too, maybe incorrectly, but the latter may be important to support.
It does not actually support the second. The reason in Windows for allowing the
window to decide whether to activate or not is because windows with "holes" in
them, think of like the winamp skins more than a decade ago (for illustration:
https://cdn.fishki.net/upload/post/2017/04/15/2268689/tn/840be11454bc68b1a93aa1d3f19c2c48.jpg).
A WM_HITTEST is sent to the window, to test what window element a click hit,
then a WM_MOUSEACTIVATE with the hittest result to figure out if the window
wants to activate itself. If the window was activated as a result, the same
action is sent as the message belonging to it - for example a WM_NCLBUTTONDOWN.
Wine on the other hand never does a HITTEST, and sends a WM_MOUSEACTIVATE on a
HTMENU which often is impossible because the app does not have a menu. Then
does not follow it up with the appropriate message - because it cannot, since
we have no idea where a menu is, if it even exists in the first place, and that
message requires a coordinate. As you can expect, click-through windows dont
work in wine because this.

> Also, I don't know if it's possible, but maybe it is possible for some windows to not appear in the Alt-Tab list, and so only the latter case applies for them.
this is possible, for windows with WS_EX_TOOLWINDOW style. I haven't really
investigated their behavior (yet). Worst case we can just keep the behavior if
the window has this style.

At the core, this problem is about that we receive a click on something (the
caption) that doesn't exist to the win32 program, and thus we cannot fake /
pass through a click on it. You could try to say "let's render the caption
then, and cut it off when displaying", however windows apps are allowed to draw
whatever in the caption, or move it anywhere by just implementing WM_HITTEST so
we cannot possibly know where the - if any - caption is.

Part of the issue can be solved perfectly however: As long as the click goes to
the client area, we could properly implement it (hittesting and all that stuff)
and gain support to windows with holes in them like winamp. This would also
solve half of this issue, since as long as you clicked into the window and not
on the caption, activation would work as expected.

As for the other part, we only have 3 other choices:
- wontfix (sounds like you're leaning towards this?)
- simulate alt-tab instead (my suggestion)
- just add some random hack that makes unity work and hopefully doenst break
other stuff (pretty much David's poc, with maybe a little bit more throught put
into which message we should fake)

> If the check is removed, then we can remove all WM_TAKE_FOCUS related code altogether
because of the mentioned TOOLWINDOW stuff we might want to keep this around,
for tool windows at least.

> Then this may require some investigation, UseTakeFocus=No should not change the focus loss behavior, only the focus gain on Wine windows.
I'll check back on this, was a 2 minute check of running an unity test program,
could've been that my test environment was dirty from some stuff I tried
before.

As for the remaining problem (Unity jumping in the middle after fixing the
activation issue) I think it's a clear-cut case, we just need to have those two
messages sent.

-- 
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.