[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 #16 from w at zeroitlab.com ---
> Sure, maybe HTMENU wasn't the best choice. I don't really know how that works and if there would be a better, safe, choice.
None that is mouse interaction based, because they all need a position. And we
 - cannot submit coords for the real elements because win32 doesn't know of the
linux WM's decorations
 - cannot submit made-up coords for things inside the window because win32 apps
can place anything anywhere - noone stops them from putting the caption at the
bottom by implementing NCPAINT and HITTEST

This is exactly why I suggested alt-tab style switch emulation, since that
doesn't need any coordinates, and wouldn't cause much of a regression
considering we're doing it wrong currently anyways. And noone seems to have
cared when it was swapped from HTCAPTION to HTMENU either. It also turned out
that the alt-tab part is irrelevant, because technically it could be absolutely
anyone calling SetForegroundWindow on our window which results in the same
behavior - I just tested this with making a WS_EX_TOOLWINDOW and activating via
Process Hacker. 

> Not at all, just that the issue has complex implications (which I don't even know the extend of) and it doesn't seems easy to fix.
Proper fix indeed has many implications, and is hard to make. However, as for
the one I suggested - about all implications would be happening anyways since
the HTCAPTION -> HTMENU change. In short, it is about as incorrect as the
current code, however at least it's something that can happen in Windows.

> 1) Windows that cannot be activated through alt-tab on windows.
Since the messages seem to be able to happen by anyone's call to
SetForegroundWindow this is now quite irrelevant to this issue. However I did
test and wine indeed does not hide my window of WS_EX_TOOLWINDOW from linux
alt-tab. Probably should be tracked in a separate issue.

> 2) ... maybe it's just not feasible if we don't have the geometry of the window and only hittest at our disposal.
This is indeed the case, we can only work with HITTEST, because visible
transparency and hit-transparency is different. I haven't used XShape so I
don't really know what it needs to work.

> 3) As a fallback, possibly try to determine more precisely the source of the focus change, checking cursor position and button state maybe, to simulate the click when appropriate, and alt-tab when not.
This is why I split the issue into two cases in my previous comment, if we're
going for most correct solution possible, this would be that.

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