http://bugs.winehq.org/show_bug.cgi?id=58107
Bug ID: 58107 Summary: PlayOnline Viewer: Minimised window restores behaving as if it was inactive. Product: Wine Version: 10.5 Hardware: x86-64 URL: https://web.archive.org/web/20210810150839/http://www. playonline.com/ff11eu/download/media/install_win.html OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs@winehq.org Reporter: chiitoo@gentoo.org Regression SHA1: 3ae66c75cf443c0be403d9fe4e4da3c19b3ad9a8 Distribution: Gentoo
After 3ae66c75cf4 [1], PlayOnline Viewer sometimes restores from a minimised state behaving as if it was not the active window.
Normally, when the PlayOnline Viewer window is visible but not the active window, it will lower its FPS to ~5 and the mouse cursor will not change over it, nor do the buttons respond to the cursor until the window is activated.
Once it is the active window, the FPS for me will be above 40 depending on what is on the screen, and the mouse cursor is a custom cursor from the application.
With the mentioned commit, the application window acts as if it is not the active window, with the reduced FPS and non-custom cursor, but it responds to clicks on buttons and such as usual when it is the active window.
This does not happen 100% of the time, sometimes taking a handful or minimise/restore actions.
Thank you!
1. https://gitlab.winehq.org/wine/wine/-/commit/3ae66c75cf443c0be403d9fe4e4da3c...
http://bugs.winehq.org/show_bug.cgi?id=58107
Chiitoo chiitoo@gentoo.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression
http://bugs.winehq.org/show_bug.cgi?id=58107
Chiitoo chiitoo@gentoo.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|PlayOnline Viewer: |Unexpected change in window |Minimised window restores |activation and raise |behaving as if it was |behaviour. |inactive. |
--- Comment #1 from Chiitoo chiitoo@gentoo.org --- I've noticed that 3ae66c75cf4 causes other changed behaviour as well.
When Final Fantasy XI Online is launched (via the PlayOnline Viewer), there is an opening movie played (which can be disabled, not sure if needed to see this happen), and when almost any key is pressed, it will be skipped.
In full-screen windowed mode, and during that that transition, if I move the window to a secondary monitor, and wait for the first menu screen to load, the game normallly moves the mouse cursor on one of the two menu buttons.
However, with the mentioned commit, the mouse jumps to where the button would be on the primary screen (where the clicks will go as well).
Furthermore, the mouse cursor isn't registered over the buttons at all before the window is in some other way activated.
Additionally, I'm using KWin (X11) as my Window Manager, and I have set Window Behaviour / Window ACtions so that middle and right clicks 'Activate and pass click'. This means such clicks will activate windows, but not raise them.
After the mentioned commit, they /almost/ always raise the window as well.
This last mentioned behaviour can be easily tested with something like the Wine notepad application, which so far seems to always raise the window.
With that in mind, I suspect this affects /any/ application in some way that is running via Wine.
Have not tested other Window Managers yet.
http://bugs.winehq.org/show_bug.cgi?id=58107
Chiitoo chiitoo@gentoo.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |290fd532ee7376442d272e38335 | |28256bfe5e9dc
--- Comment #2 from Chiitoo chiitoo@gentoo.org --- After, or at commit 290fd532ee7 [2], testing restoring at least 111 times from minimised state did not trigger the issue yet.
At the previous commit, bf0813e3947 [3], it usually happens in one try, so I think it is someawhats safe to say that /that/ part has been fixed.
Thank you!
2. https://gitlab.winehq.org/wine/wine/-/commit/290fd532ee7376442d272e383352825... 3. https://gitlab.winehq.org/wine/wine/-/commit/bf0813e39470c5682c784b1db9812fb...
http://bugs.winehq.org/show_bug.cgi?id=58107
--- Comment #3 from Chiitoo chiitoo@gentoo.org --- Hrm. I noticed the issue was back, and bisecting it, it keeps happening with commit 290fd532ee7 as well again, so not sure what was going on there.
I can at least still re-produce the issue starting with 3ae66c75cf4...
http://bugs.winehq.org/show_bug.cgi?id=58107
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
--- Comment #4 from Rémi Bernon rbernon@codeweavers.com --- It's not completely clear to me what this bug is exactly about, could we focus on a specific problem to fix, and eventually split the other issues in separate bugs?
For instance the original issue seems to be that restoring a window from a minimized state isn't properly notified to the application, could you confirm that this specific problem is happening again with latest Wine?
If yes, could you attach a WINEDEBUG=+timestamp,+pid,+tid,+loaddll,+x11drv,+event,+win,+msg,+message log after minimizing then restoring the window, until it fails?
http://bugs.winehq.org/show_bug.cgi?id=58107
--- Comment #5 from Chiitoo chiitoo@gentoo.org --- (In reply to Rémi Bernon from comment #4)
Yeah, I was going to say, best keep this about that specific issue.
That written, I'm seeing the behaviour again where it stops at commit 290fd532ee7... so I'll need to test things even more and report back later.
http://bugs.winehq.org/show_bug.cgi?id=58107
Chiitoo chiitoo@gentoo.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Summary|Unexpected change in window |PlayOnline Viewer: Window |activation and raise |not activated when |behaviour. |restoring from a minimised | |state. Resolution|--- |FIXED
--- Comment #6 from Chiitoo chiitoo@gentoo.org --- It looks like I am unable to re-produce still after 290fd532ee7, and have no clue on what was going on earlier.
I suppose we'll have to call this one fixed. :]
I'll look into reporting the other issues separately.
Thank you!
http://bugs.winehq.org/show_bug.cgi?id=58107
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 10.10.
http://bugs.winehq.org/show_bug.cgi?id=58107
--- Comment #8 from Chiitoo chiitoo@gentoo.org --- Of course this issue /now/ returns once more again, without anything really having changed, and even though it was very consistent during so many test runs.
Maybe it's affected by the time of day or something...
Will try to find out what is going on via even more testing at some point.
http://bugs.winehq.org/show_bug.cgi?id=58107
--- Comment #9 from Chiitoo chiitoo@gentoo.org --- Created attachment 78783 --> http://bugs.winehq.org/attachment.cgi?id=78783 Application Window Minimised and Restored Once
Did not get to testing things out even more yet, but here's at least the requested log from when the issue happens at current point in time (Wine 10.10).
http://bugs.winehq.org/show_bug.cgi?id=58107
Chiitoo chiitoo@gentoo.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|CLOSED |UNCONFIRMED
--- Comment #10 from Chiitoo chiitoo@gentoo.org --- One new observation: The window manager might play a part here too, since so far I am unable to re-produce this using Openbox, while it again/still rather consistently happens while using KWin (X11).
In any case, it does look like I declared this fixed too soon, and I can not find a commit that would have re-introduced the issue either.
Apologies for that!