https://bugs.winehq.org/show_bug.cgi?id=43691
Bug ID: 43691 Summary: focus tracking broken with desktop switches Product: Wine Version: 2.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs@winehq.org Reporter: galtgendo@o2.pl Distribution: ---
When window manager is set to focus-follows-mouse (not sure if this bit is important, but rest would be unclear without this bit) and winecfg sets it to decorate/manage the windows, if I switch to a different window on the same desktop (which makes most apps in question pause) then switch to a different desktop, next switch back to the apps desktop, the app decides to act as if it regained the focus and unpauses, even if it shouldn't, cause it's whole window is covered by other windows. If more than one wine app is on that desktop, it seems to be a random pick. What's more, some of the time it seems to be receiving keyboard events, even if at the same time they go to a different window.
("desktop" refers to manager's desktop not wine's virtual desktop window (which isn't in use here))
https://bugs.winehq.org/show_bug.cgi?id=43691
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl --- Created attachment 59199 --> https://bugs.winehq.org/attachment.cgi?id=59199 don't treat switching to a different desktop as iconization
Attaching the little hack sent to wine-patches.
It sort of works, but creates a different problem, where if there are more than one wine windows open and one with focus is closed, focus may jump to a window that's not on the current desktop.
https://bugs.winehq.org/show_bug.cgi?id=43691
--- Comment #2 from Rafał Mużyło galtgendo@o2.pl --- *** Bug 44461 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=43691
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #59199|0 |1 is obsolete| |
--- Comment #3 from Rafał Mużyło galtgendo@o2.pl --- Created attachment 60409 --> https://bugs.winehq.org/attachment.cgi?id=60409 updated version
So, I've missed one more array the atom needed to be added into.
The mapping lines aren't fully tested yet, but are likely a move in the correct direction.
https://bugs.winehq.org/show_bug.cgi?id=43691
Vijay Kamuju infyquest@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |infyquest@gmail.com
--- Comment #4 from Vijay Kamuju infyquest@gmail.com --- send this patch to wine-devel@winehq.org for review
https://bugs.winehq.org/show_bug.cgi?id=43691
--- Comment #5 from Rafał Mużyło galtgendo@o2.pl --- *** Bug 41968 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=43691
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzhang@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=43691
--- Comment #6 from Rafał Mużyło galtgendo@o2.pl --- If you find terminology I use confusing, see https://en.wikipedia.org/wiki/Virtual_desktop.
https://bugs.winehq.org/show_bug.cgi?id=43691
--- Comment #7 from Rafał Mużyło galtgendo@o2.pl --- So as for comment 1: it looks like that's actually unrelated to my patch, but a part of bug 48368.
https://bugs.winehq.org/show_bug.cgi?id=43691
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|user32 |winex11.drv
https://bugs.winehq.org/show_bug.cgi?id=43691
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=43691
--- Comment #8 from Rafał Mużyło galtgendo@o2.pl --- ...perhaps I should mention, that for quite a while, the version of the patch I've been using has dropped most of the chunks for event.c, except a single one - the last one in comment 3 patch (one calling read_net_wm_states).
I haven't invested any serious effort into investigating bug 48368 problem.
https://bugs.winehq.org/show_bug.cgi?id=43691
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #60409|0 |1 is obsolete| |
--- Comment #9 from Rafał Mużyło galtgendo@o2.pl --- Created attachment 67683 --> https://bugs.winehq.org/attachment.cgi?id=67683 updated patch
This is currently most recent version of the patch, that's been sent to the list for comments.
For the moment very little testing had been done, just checking it's not obviously broken.
https://bugs.winehq.org/show_bug.cgi?id=43691
Gabriel Ivăncescu gabrielopcode@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gabrielopcode@gmail.com
--- Comment #10 from Gabriel Ivăncescu gabrielopcode@gmail.com --- I don't think this is related to bug 15346 (or patch 194655, which is due to X11 difference wrt to fullscreen state compared to Windows), but it does seem to be an interesting case Wine still doesn't handle.
I believe I mentioned previously on the mailing list, but this should probably be implemented via DWMWA_CLOAKED instead of disabling/enabling the window. It should probably be a flag in user32's window. But the main dilemma I have is how to get/set it from another module (dwmapi probably)? I know Alexandre is heavily against extra wine-specific exports unless absolutely necessary, in this case, one from user32 would suffice.
Anyway, do you have a quick testcase to test this behavior? It can be a simple selfmade app or anything just to show whether it works and why it doesn't work correctly currently.
https://bugs.winehq.org/show_bug.cgi?id=43691
--- Comment #11 from Rafał Mużyło galtgendo@o2.pl ---
do you have a quick testcase to test this behavior?
Well, nothing off the top of my head, but I've run into multiple simple games and game-like apps that pause audio upon loosing focus, but don't minimize.
In those, the simplest way to show the problem is to run the app, switch to a different window on the same desktop to get the app to pause, then switch to a different desktop and switch back.
Without this patch, the apps treat minimize/unminimize cycle that wine does as if they were regaining focus and unpause (start playing music). But this shouldn't be the case if they aren't *actually* regaining the focus.
https://bugs.winehq.org/show_bug.cgi?id=43691
--- Comment #12 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Created attachment 68567 --> https://bugs.winehq.org/attachment.cgi?id=68567 Implement cloaking
Here's a patch that implements cloaking. It's quite big because it implements manual cloaking as well (which an app can) by setting the opacity of an X window to zero and making it invisible to mouse input via XShape. It uses the undocumented user32 API SetWindowCompsitionAttribute that I have written tests for (not in this patch). Of course an app will probably use DwmSetWindowAttribute instead, which will be just a wrapper to this eventually.
The shell cloaking itself is not big, but it should do what you needed. I tested on Windows 10 to mimic its behavior and indeed, windows on a different Virtual Desktop cannot be set to foreground (it fails), while manually cloaked windows can, so I only made it fail on "shell cloaked" windows (those are the windows that are hidden by the WM on a desktop switch).
Please test and let me know if it works for you. Don't forget to run tools/make_requests after applying the patch in the wine directory.
Obviously I will split it up and add tests when sending it upstream, this is just a preliminary look at it and looking for comments/testing.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla