Significant delay when closing any app window/dialog which was started with Wine #3478
Comments
|
With full debug enabled: The window itself: So the window claims to support Based on this wine ticket: Lot of wait_for_withdrawn_state when running with xvfb-run and wine fixme wait_for_withdrawn_state window - the claim made there is that the window is withdrawn. Unfortunately, as can be seen above, the window is definitely not in a withdrawn state: # xprop | grep -i state
WM_STATE(WM_STATE):
window state: Normal
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FOCUSED, _NET_WM_STATE_SKIP_TASKBAR
Initial state is Normal State.
# xwininfo | grep "Map State:"
Map State: IsViewableUnless wine is waiting for the window to be withdrawn by xpra instead? And I don't see any message in there that should make us withdraw the window.. |
|
Thanks @totaam, this helps a lot to understand what is going on. I initially thought that this is an xpra issue because when explicitly using a different window manager (openbox) then everything works fine: I think for now, I will use openbox. |
|
Further, none of the X11 property messages should affect the window's visibility:
|
|
With ( And xpra sends a 100% identical message: So whatever logic makes wine behave differently is not related to the Looking at this from the other end. wait_for_withdrawn_state is the function that triggers the warning, it is called from: Only the latter is relevant here and is called from: It's really not clear to me which one is being called! |
|
Upstream wine ticket: wait_for_withdrawn_state |
|
I don't think winehq's bug tracker is very active. Without clarifications from the developers, there is absolutely nothing I can do here. |
|
Running with TILS:
|
|
wine is sending the Which is why we never see this event and I will have a workaround for this. |
|
Maybe nothing to do with the root window, we just don't get the But when the application calls The spec says: To receive Similar symptoms in other projects:
The difference is that they were not withdrawing the window by updating |
|
Looking at the X11 server source: #define SubSend(pWin) \
((pWin->eventMask|wOtherEventMasks(pWin)) & SubstructureNotifyMask)
#define StrSend(pWin) \
((pWin->eventMask|wOtherEventMasks(pWin)) & StructureNotifyMask)
#define SubStrSend(pWin,pParent) (StrSend(pWin) || SubSend(pParent))So it checks DeliverEvents |
|
Running
Does not show the So the event is not forwarded by the X11 server. Why? |
|
Running a modified And not the main window. When running under So my new working hypothesis is that despite us sending the correct window with the I believe this is where it ends up calling |
|
Also tried via |
|
ICCCM 4.1.3.1. WM_STATE Property: So we were causing short reads, and wine defaults to This was another 16 year old bug! |
|
Thanks a lot for your dedication and the significant amount of time you spent on this issue, I really appreciate it! Looking forward to upgrading to v5.0.6 |
Describe the bug
When using the built-in window manager in Xpra and launching an application under Wine, there is a significant delay (for me it is around 3 seconds) when closing any window or dialog box.
To Reproduce
Steps to reproduce the behavior:
xpra start --daemon=no --start=winecfgxpra attachwinecfgis a built-in configuration app which comes with Wine, but the issue can be reproduced with any app running under Wine. To reproduce (whenwinecfgloads), click "Add application..." to open up a dialog box, then click "Cancel". There will be a delay of approximately 3 seconds before the dialog box closes and on the server console, a Wine log message will be printed:This issue does not happen if I use another window manager, e.g. Openbox. But, I would really prefer to use the built-in window manager of Xpra.
System Information (please complete the following information):
Additional context
Add any other context about the problem here.
Please see "reporting bugs" in the wiki section.
The text was updated successfully, but these errors were encountered: