[Bug 48121] New: Unity games do not fire OnApplicationFocus/OnApplicationPause events on focus regain
https://bugs.winehq.org/show_bug.cgi?id=48121
Bug ID: 48121 Summary: Unity games do not fire OnApplicationFocus/OnApplicationPause events on focus regain Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs@winehq.org Reporter: dt@zeroitlab.com Distribution: ---
Created attachment 65713 --> https://bugs.winehq.org/attachment.cgi?id=65713 Proof of concept patch
I've tested with both stable and staging, neither gets unity to fire OnApplicationFocus and OnApplicationPause events on focus regain. I've tracked this down by reverse engineering the native unity binary.
There are 4 window messages to which the unity engine reacts by firing these internal events. They are: 1. WM_SIZE (when wParam == 0 && unity's window is active) 2. WM_EXITSIZEMOVE 3. WM_NCPOINTERUP 4. WM_NCPOINTERDOWN (when DragDetect() says the pointer is in bounds for the window; pointer coordinates are passed in lparam)
Of all these events, it seems to me, that the ones we should be firing and are not currently, are WM_NCPOINTERUP and WM_NCPOINTERDOWN.
I was not sure how to get the pointer coordinates, but I was able to confirm this finding, by firing WM_NCPOINTERUP with wparam=0, lparam=0 on focus regain because that event had no such bounds check in the unity engine code. With this change, my target application indeed unpauses.
Observing the issue is fairly easy, https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnApplicationFocus.ht... adding this example behaviour to the camera and building the project for windows then running it in wine reproduces.
https://bugs.winehq.org/show_bug.cgi?id=48121
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |4.20 Keywords| |patch
--- Comment #1 from Ken Sharp imwellcushtymelike@gmail.com --- Patches don't normally get picked from here.
Have a look at https://wiki.winehq.org/Submitting_Patches The wine-devel list is a good place to send it if you just want someone to look at it first, though you can of course include the link to this bug report.
https://bugs.winehq.org/show_bug.cgi?id=48121
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- (In reply to Ken Sharp from comment #1)
Patches don't normally get picked from here.
Have a look at https://wiki.winehq.org/Submitting_Patches The wine-devel list is a good place to send it if you just want someone to look at it first, though you can of course include the link to this bug report.
Given the patch is explicitly marked "proof of concept", I suspect it's not meant to be committed directly.
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #3 from David Torok dt@zeroitlab.com --- (In reply to Zebediah Figura from comment #2)
(In reply to Ken Sharp from comment #1)
Patches don't normally get picked from here.
Have a look at https://wiki.winehq.org/Submitting_Patches The wine-devel list is a good place to send it if you just want someone to look at it first, though you can of course include the link to this bug report.
Given the patch is explicitly marked "proof of concept", I suspect it's not meant to be committed directly.
That is right :)
I am by no means knowledgeable in this windows subsystem; so I'm not even sure why "non-client" areas trigger this behaviour in unity. Is this "client"/"non-client" terminology the same as in Xorg/Wayland "client" terms? If so, then "non-client area" to me, sounds like the border/window outline. According to https://msdn.microsoft.com/zh-cn/ie/hh454917(v=vs.80) it's "Posted when a pointer makes contact over the non-client area of a window". It does not make sense to me why this interaction triggers the focus regain.
So indeed, this is definitely not for being taken directly.
https://bugs.winehq.org/show_bug.cgi?id=48121
juliansperling@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juliansperling@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=48121
Jorge Pinilla Lopez tarmabal@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tarmabal@gmail.com
--- Comment #4 from Jorge Pinilla Lopez tarmabal@gmail.com --- I am talking from complete ignorance so excuse me if I am wrong.
This bug is said to be the cause of disconnections in Legends of Runeterra
https://lutris.net/games/legends-of-runeterra/
https://www.reddit.com/r/leagueoflinux/comments/dset58/legends_of_runeterra_...
Is it true? Do we know if the PoC fixes the problem?
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #5 from David Torok dt@zeroitlab.com --- (In reply to Jorge Pinilla Lopez from comment #4)
I am talking from complete ignorance so excuse me if I am wrong. This bug is said to be the cause of disconnections in Legends of Runeterra Is it true? Do we know if the PoC fixes the problem?
That is not true. This bug is responsible for the game becoming unresponsive after losing and regaining focus. The disconnect issue is unrelated. I've spent a fair bit of time trying to track down the root cause of the disconnect bug but without success. The PoC on this bug does fix the focus issue, and has no effect on the disconnect issue.
https://bugs.winehq.org/show_bug.cgi?id=48121
herve@guillemet.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |herve@guillemet.org
--- Comment #6 from herve@guillemet.org --- Similar problem happens with Pokemon TCG Online, another Unity Card game. (All versions of wine 5 up to 5.16). Using a virtual desktop works around the issue.
https://bugs.winehq.org/show_bug.cgi?id=48121
impurered58@riseup.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |impurered58@riseup.net
--- Comment #7 from impurered58@riseup.net --- This is caused caused by this code: https://github.com/wine-mirror/wine/blob/master/dlls/winex11.drv/event.c#L70... recently changed - but not fixed - in this commit: https://github.com/wine-mirror/wine/commit/cfcc280905b7804efde8f42bcd6bddbe5...
Unity only decides to activate for WM_ACTIVATE if the last WM_MOUSEACTIVATE has hit HTCLIENT.
On Windows, this serves so that the window isn't active while dragging the window using caption, and only activates on release, which is why the PoC patch works.
I'd recommend rolling back the mentioned commit, and simulating a click and a release on the caption. This would both replace the fix of the commit, and fix this issue.
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #8 from w@zeroitlab.com --- On a second look fixing the issue might be a bit more complicated. Looking a bit further into the behavior of clicking on the caption on wine, wine with virtual desktop, and windows, the behavior is the following:
- Wine on X11: window receives a WM_MOUSEACTIVATE on a HTMENU (regardless if it actually has any menus or not), then depending on the reply it activates the window - Windows and Wine with virtual desktop: window receives a WM_MOUSEACTIVATE on a HTCAPTION, ignores the window's wish to not be activated and activates it anyways, then later the window receives a WM_NCLBUTTONDOWN. This makes Unity work.
There are two okay-ish ways to fix this: - Make the X11 implementation either not test anything, or test HTCAPTION and ignore result and send a WM_NCLBUTTONDOWN after. - Send a WM_NCLBUTTONDOWN after testing for HTMENU. This is somewhat a band-aid fix since the program will still receive a WM_MOUSEACTIVATE with HTMENU even if it has no menus at all, however we can keep the current activation behavior.
https://bugs.winehq.org/show_bug.cgi?id=48121
Ker noa blue-t@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |blue-t@web.de
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #9 from w@zeroitlab.com --- I looked at this issue again and possible fixes to it. Unfortunately faking a caption / menu click is not really reliable to do, since neither of those are guaranteed to exist at all, and even if they do we can't know where they are located. I tried sending a WM_NCLBUTTONDOWN at 0,0 but it just hung the program so I didn't bother more with that. I was thinking what else we could do to follow Windows behavior more correctly. Obvious "fix" would be properly getting mouse cursor, hittesting, etc.. but that's quite complex, and we'd still have problems with when people alt-tab or click the caption. So the next best thing would be simulating some app switch in windows that doesn't have interaction with the window, like alt-tab. I wrote a simple C++ program to dump events sent by Windows (https://zerobin.net/?f96a3d885e1ced60#mGNqn2ultaBbuVNuZrnszC0hWlWau+yhHRGUKa...) and alt-tabbed into it on a Win8 install. Ignoring some irrelevant or undocumented junk, following events are received by my program:
WM_WINDOWPOSCHANGING 00000000 0050F808 -> 00000000 lParam: 00000003 (0 0 0 0) 000401BC 000401B6 WM_WINDOWPOSCHANGED 00000000 0050F808 -> 00000000 lParam: 00001803 (216 466 200 200) 000401BC 000401B6 WM_ACTIVATEAPP 00000001 000008E8 -> 00000000 WM_NCACTIVATE 00000001 00000000 -> 00000001 WM_SETFOCUS 00000000 00000000 -> 00000000 WM_ACTIVATE 00000001 00000000 -> 00000000
So indeed, no WM_MOUSEACTIVATE happens in this case which means this: https://github.com/wine-mirror/wine/blob/master/dlls/winex11.drv/event.c#L70... can be simply removed and implemented as if it was MA_ACTIVATE at all times (not simulating clicks would cause regression with click-through windows if they were supported, but we don't support that anyways) since Windows does this too. After changing this, Unity window does detect application focus, however the window jumps in the middle (this also happens with David's PoC patch). This is due to the missing WINDOWPOSCHANGING / WINDOWPOSCHANGED. These two are sent in all cases when a window is activated, so might be better to implement in set_focus. I ended up sending the messages manually since couldn't quite figure out how to get SetWindowPos send them (maybe also needs changes).
https://bugs.winehq.org/show_bug.cgi?id=48121
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
--- Comment #10 from Rémi Bernon rbernon@codeweavers.com --- The code in winex11.drv is clearly incorrect w.r.t what Windows does, especially for focus gained through means other than mouse click (alt-tab or other), but I believe it's there for a reason. I don't remember exactly the kind of scenario we need it for, but removing it will break some cases.
FWIW, winex11.drv has a UseTakeFocus configuration option to not use WM_TAKE_FOCUS message, and that can be used to immediately give focus to windows, without sending this message (effectively doing what you suggests but without modifying the code). Proton uses that by default.
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #11 from w@zeroitlab.com ---
I don't remember exactly the kind of scenario we need it for, but removing it will break some cases.
I'm not exactly sure if breaking those cases isn't the right thing to do, because they won't work on real Windows in the first place (since programs that do require WM_MOUSEACTIVATE won't get that on actual Windows with alt-tab either). This line of code was added 18 years ago: https://github.com/wine-mirror/wine/commit/1a80921903a1d9a21aecca3aea6673e83... I went ahead and checked the messages on Windows 2000 to make sure, and it does not send anything other than what I listed earlier either, so this is not a "recent" change brought with DWM either.
UseTakeFocus makes Unity not lose focus in the first place, so is not a perfect solution, but does make most games playable.
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #12 from Rémi Bernon rbernon@codeweavers.com --- Well sure it's old but it's also been there for a while, not breaking other apps, and probably serves a purpose. I personally don't clearly remember, and perhaps nobody does, but that doesn't mean the code is useless.
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. The code covers the former too, maybe incorrectly, but the latter may be important to support. 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 former case applies for them.
Also FWIW, the WM_TAKE_FOCUS X11 message is only used to conditionally give focus with this check. If the check is removed, then we can remove all WM_TAKE_FOCUS related code altogether, which is essentially the same as using UseTakeFocus=No. Using that option should be doing exactly the same thing as removing the check.
UseTakeFocus makes Unity not lose focus in the first place, so is not a perfect solution, but does make most games playable.
Then this may require some investigation, UseTakeFocus=No should not change the focus loss behavior, only the focus gain on Wine windows.
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #13 from Rémi Bernon rbernon@codeweavers.com ---
and so only the former case applies for them.
s/former/latter/
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.
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #15 from Rémi Bernon rbernon@codeweavers.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.
As for the other part, we only have 3 other choices:
- wontfix (sounds like you're leaning towards this?)
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.
Plus Wine focus already doesn't match the X11 state in some cases. It's usually quite harmless, but it's something that goes beyond this particular issue and that could also make it worse.
- 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)
I think a good fix would be to determine precisely where this is used and implement a better solution for each case. If I understand correctly there at least these cases that may be covered by this code and that could be improved:
1) Windows that cannot be activated through alt-tab on windows. We can probably use EMWH atoms to make the window ignore alt-tab in that case. There's some _NET_WM_STATE atoms (_NET_WM_STATE_SKIP_TASKBAR or _NET_WM_STATE_SKIP_PAGE) that should match that, assuming the WM implements it. We should of course query its capabilities first, and provide a fallback path.
2) Transparent click-through windows. I don't know if that's ever been considered already, of if it would even work, but I believe X11 has some ways to make windows transparent and click-through using the XShape extension. Maybe implementing it using it would be better, or maybe it's just not feasible if we don't have the geometry of the window and only hittest at our disposal.
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. It's probably going to be hard, as X11 doesn't provide any information, sadly.
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #16 from w@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.
- 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.
- ... 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.
- 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.
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #17 from David Torok dt@zeroitlab.com --- Created attachment 68330 --> https://bugs.winehq.org/attachment.cgi?id=68330 yet another WIP patch
Based on the first round of feedback, I made another patch.
This removes the HTMENU click test, which as far as I understand should be in line with windows behavior when the window re-actives using Alt + Tab. (This solves the original issue)
However, as mentioned, another issue (which probably should be tracked separately) is that on re-activation the window snaps back to the center from it's current position in the case of Unity. To resolve that, we started comparing the WM sequences and noticed windows also sends WM_WINDOWPOSCHANGING and WM_WINDOWPOSCHANGED on reactivation. To follow the proper behavior more closely, I also added that to the patch. (Can't hurt?)
That did not resolve the snapping back to center issue, so more root cause analysis is to be done.
https://bugs.winehq.org/show_bug.cgi?id=48121
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |galtgendo@o2.pl
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #18 from w@zeroitlab.com --- Created attachment 68428 --> https://bugs.winehq.org/attachment.cgi?id=68428 PoC unity app part 1
needs corefonts
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #19 from w@zeroitlab.com --- Created attachment 68429 --> https://bugs.winehq.org/attachment.cgi?id=68429 PoC unity app part 2
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #20 from w@zeroitlab.com --- Created attachment 68431 --> https://bugs.winehq.org/attachment.cgi?id=68431 Restoring position poc
After a bit of reversing I managed to reproduce the jumping in the middle bug in wine with a few lines of C. The provided code doesn't change position on windows, however on wine it jumps to it's original position. Not sure yet what exactly is wrong with wine's code though.
https://bugs.winehq.org/show_bug.cgi?id=48121
Anya maniikarabera@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maniikarabera@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #21 from Ker noa blue-t@web.de --- Desperados 3 crashes with this patch applied on top of wine-staging in the current git version.
https://bugs.winehq.org/show_bug.cgi?id=48121
Brendan Shanks bshanks@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bshanks@codeweavers.com
--- Comment #22 from Brendan Shanks bshanks@codeweavers.com --- I'm still hitting this bug, including with the FPS test example from with Unity 2020.3. Removing the WM_MOUSEACTIVATE message fixes it, both on Mac and Linux/X11.
https://bugs.winehq.org/show_bug.cgi?id=48121
Jan Braun janbraun@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |janbraun@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=48121
tinozzo123@tutanota.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tinozzo123@tutanota.com
https://bugs.winehq.org/show_bug.cgi?id=48121
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |faalagorn@gmail.com
--- Comment #23 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- *** Bug 50571 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=48121
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #24 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Also affects Crowns and Pawns Kingdom of Deceit Demo (Unity game) ran from the windows Steam client under Wine 7.0-rc6.
https://store.steampowered.com/app/1125910/Crowns_and_Pawns_Kingdom_of_Decei...
The demo is stuck at the main menu screen with no way to do anything: No mouse or keyboard input.
Setting UseTakeFocus to 'N' in registry keeps the issue away.
It seems that the Steam client always does some focus switching while launching games and that probably explain why they had to set UseTakeFocus to 'N' by default in proton.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=48121
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |theli.ua@gmail.com
--- Comment #25 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- *** Bug 45937 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=48121
Reonaydo tuupic@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tuupic@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #26 from Rafał Mużyło galtgendo@o2.pl --- I'm nearly certain Steam client doesn't play a role here, it a pure Unity engine issue - I've seen it in non-Steam Unity games.
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #27 from Ker noa blue-t@web.de --- 7.1-staging and Yooka-Laylee and the Impossible Lair are affected by this still.,
https://bugs.winehq.org/show_bug.cgi?id=48121
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/user32-alttab-fo | |cus Status|NEW |STAGED CC| |leslie_alistair@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=48121
Andrew Church achurch+wine@achurch.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |achurch+wine@achurch.org
--- Comment #28 from Andrew Church achurch+wine@achurch.org --- *** Bug 53663 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=48121
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thieujank@gmail.com
--- Comment #29 from Fabian Maurer dark.shadow4@web.de --- *** Bug 54186 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #30 from Jan Braun janbraun@gmx.net --- I'm affected by this bug as well, and setting UseTakeFocus=N works around it. This is very surprising, because my WM (ratpoison) does not support WM_TAKE_FOCUS at all, and I think it indicates a bug in wine:
The way I read https://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7 , the WM_TAKE_FOCUS machinery is merely an additional way the WM may use to assign focus to wine. Setting the WM_PROTOCOLS property indicates that wine is prepared (and prefers) to receieve the WM_TAKE_FOCUS ClientMessage instead of being focused directly. It must still be prepared to receive the focus directly. (If that's not obvious, consider the "A client could receive WM_TAKE_FOCUS when opening from an icon..." sentence, which would be meaningless if the client was supposed to only ever get focused via WM_TAKE_FOCUS.) Thus UseTakeFocus=Y should have only 2 effects: setting the atom in WM_PROTOCOLS (and possibly the input field in WM_HINTS), and handling the ClientMessage. If the WM doesn't support WM_TAKE_FOCUS (nor WM_HINTS), the former is inconsequential, and the latter will never be received. Therefore, the value of UseTakeFocus should not be able to change observable behaviour.
However, in X11DRV_FocusIn(), wine *does* things differently depending on the value of use_take_focus (winex11.drv/event.c:802). That's as far as I got, hopefully somebody with more familiarity with the wine code base can figure out what wine is trying to achieve with that distinction, and what the proper handling should be.
https://bugs.winehq.org/show_bug.cgi?id=48121
Neko-san nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=48121
random-nick@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |random-nick@mail.com
https://bugs.winehq.org/show_bug.cgi?id=48121
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #31 from Fabian Maurer dark.shadow4@web.de --- Also affects "Out of Ctrl", which is pretty small and makes it easy to test: https://miknugget.itch.io/out-of-ctrl
https://bugs.winehq.org/show_bug.cgi?id=48121
soredake broaden_acid002@simplelogin.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|broaden_acid002@simplelogin | |.com |
https://bugs.winehq.org/show_bug.cgi?id=48121
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |es20490446e@gmail.com
--- Comment #32 from Fabian Maurer dark.shadow4@web.de --- *** Bug 57438 has been marked as a duplicate of this bug. ***
-
WineHQ Bugzilla