https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #14 from w@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/840be11454bc68b1a93...). 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.