Let me state first, that I have only replicated this with Citrix Receiver and Wfica_Seamless (class name) application windows. (https://www.citrix.com/products/citrix-cloud/try.html) Problem: Citrix wfica in seamless application mode, attempts to create a window on the RandR primary monitor. However, if the RandR primary monitor is not the bottom-most & right-most in the display configuration, xfwm4 can cause the window to be drawn on an alternate monitor based on mouse cursor activity (location). The end result is that the application is drawn (with Xv) onto the non-primary monitor, based on the coordinates and size of the RandR primary. The window is drawn on this alternate monitor, and while keyboard input is transmitted when this window is active, mouse is not as the cursor coordinates do not line up. This can be resolved by hide/minimizing the window and restoring after ~1 second. Our only workaround at this point is to ensure that the bottom-most, right-most monitor is set as RandR primary. I suspect that this is related to either https://bugzilla.xfce.org/show_bug.cgi?id=9351 or https://bugzilla.xfce.org/show_bug.cgi?id=8866 I have confirmed that this occurs in 4.10.x, and 4.12.x in our own Yocto based distribution, Xubuntu 14.04, Xubuntu 16.04, Arch Linux (fully up to date). I have tried fiddling with xfwm4-tweak-settings Placement & Focus to no avail.
I should also add, this has been confirmed to not be an issue on openbox, kde, gnome
Yes, this is likely related to bug 9351, as gtk+ reorders the monitors putting primary first and then based on decreasing size, and xfwm4 uses the gtk+ order instead of the XRandR order. Yet you mention that the result depends on the mouse cursor location? That's odd, because the only case where xfwm4 would do that is when the client doesn't specify a location. Note: I am not really willing to put my details, register and install proprietary software on my laptop, so ideally a simple reproducer would be better.
Citrix -- I can provide an account, as we are a Citrix partner, however I can not post such account in the ticket details. Mouse position -- Yes, it is tied to the mouse position. As for window position, I don't know exactly how citrix does it, but I make a small assumption that it may providing a window with a small size, and allowing the window manager to do placement, which might be tripping smart placement.
Created attachment 6670 xprop output of misplaced Citrix_Seamless window
Created attachment 6671 xwininfo output of misplaced window
Created attachment 6672 xwininfo output of misplaced window
Created attachment 6673 xwininfo output of misplaced windows parent
Created attachment 6674 xprop output of misplaced Citrix_Seamless window Excel
From the captures, it shows that it's definitely not fullscreen so not related to bug 9351 (we kinda knew that since you mentioned that the behavior depends on the mouse pointer location). The window is maximized though: _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_MAXIMIZED_VERT Motif hints tell us it's not decorated by the WM: _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0 The applications expects the window to be placed in 0,31: WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 0, 31 program specified size: 1920 by 1000 So my guess is you have a pretty default xfce setup with the panel on top (thus y=31). This is also seen in the xprop: Normal window size hints: Program supplied location: 0, 31 Program supplied size: 1920 by 1000 However the window is actually placed on the other monitor: Corners: +1920+31 -0+31 -0-180 +1920-180 Basically, the application asked for its window to be maximized in (0,31) but the WM places it on (1920,31). The WM might have good reasons not to grant the requested location (and is absolutely free to do so) and the app should adapt (it receives a configure notification with the actual location, it should use it). So, for now, I'm leading toward a bug in the application (Citrix) which wrongly assume a window location. To be sure, can you please post the output of "xrandr" in that particular setup?
Created attachment 6675 xrandr output of problem case
I wonder: - Why it is that this is not an issue on other WM - What messages or hints are delivered to cause the window to be relocated when minimized and then restored.
(In reply to Jason Plum from comment #10) > Created attachment 6675 > xrandr output of problem case DP3 connected 1440x900+1920+0 (normal left inverted right x axis y axis) 408mm x 255mm HDMI1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 476mm x 268mm So you have a 1920x1080 monitor on the left and a 1440x900 on the right next to it. The monitor on the left is at (0,0) so the requested position of (0,31) falls within that one, and yet the WM maximizes the window on the monitor on the right: Absolute upper-left X: 1920 Absolute upper-left Y: 31 Width: 1440 Height: 869 I wonder why. Could you please capture the xprop of the misplaced window's parent as well? (In reply to Jason Plum from comment #11) > I wonder: > - Why it is that this is not an issue on other WM Different window managers may have different placement policies. > - What messages or hints are delivered to cause the window to be relocated > when minimized and then restored. That's something that could be found in the client's (Citrix) source code, I cannot tell.
The parent's xprop is empty.
Would you be able to rebuild xfwm4 from sources to try a patch?
Sorry, just to clarify, I didn't mean that in a bad way, I meant willing to rather than able to (installing all the deps to build from source can be time consuming, not everyone may have the will to do it)
I can, and will. I am attaching two x11trace logs. One from openbox and one from xfwm4.
Created attachment 6676 x11trace xfwm4 x11trace (xtrace) logs for wfica (Citrix) application on xfwm4 for comparison against what occurred in openbox. This includes the re-positioning via minimize/restore.
Created attachment 6677 x11trace openbox x11trace (xtrace) of wfica on openbox for comparison against xfwm. This does not include minimize/restore
Final & problematic window is created @ - L5229 of xfwm x11trace - L5770 of openbox x11trace
Created attachment 6678 [PATCH] client: Make sure we use pre-ICCCM fields Does this patch make any difference?
I applied this to 4.12.3, with a small alteration at add the `clientGetMWMHints (c, TRUE);` in clientFrame. The result is mixed. - dialogs from wfica get thrown to the corners of the diaply on which the mouse is located. (-1) - The final window draws onto the display on which the mouse is located (+1) - The size of the final window matches the display on which the mouse is located (+1) - The mouse input is properly accepted by the final window (+1) - From maximized, Restore will relocate the final window to the Primary display. (-1), though input follows correctly (+1) - Minimize and Restore of the final window will result in the window being relocated to the Primary display (-1)
(In reply to Jason Plum from comment #21) > I applied this to 4.12.3, with a small alteration at add the > `clientGetMWMHints (c, TRUE);` in clientFrame. > [...] Nope, please try without any other change, changing the param is wrong here.
The patch does not otherwise apply to the 4.12.3 release. I will simply remove the line entirely.
Removing that edit: - final window behavior is the same (-1) - dialogs are still thrown to corners (-1)
(In reply to Jason Plum from comment #24) > Removing that edit: > - final window behavior is the same (-1) > - dialogs are still thrown to corners (-1) Sorry, I'm getting confused, could you please attach the source file client.c from your build with the patch applied?
Created attachment 6679 post-patch client.c http://git.xfce.org/xfce/xfwm4/tree/src/client.c?id=xfwm4-4.12.3#n1664
Comment on attachment 6678 [PATCH] client: Make sure we use pre-ICCCM fields (In reply to Jason Plum from comment #26) > Created attachment 6679 > post-patch client.c Oh right, my bad, I didn't realize master was so different from 4.12 in this regard. Let's forget about this patch then.
Created attachment 6680 [PATCH] placement: Don't relocate on monitor if position is specificed Could you please try this one instead (simply discard the previous changes, try this patch alone)?
Dialogs always result @ 1921,201 and final window ends up with Primary display geometry, but right,bottom-most Display
Created attachment 6682 [PATCH] placement: Relocate dialogs only Can you try this patch instead? That should nail it...
At least here, not quite. Dialogs behave as expected. Final windo still on non-primary display, though geometry is more accurate to the size of the display the mouse is/was on, it is not on the correct (primary) display.
(In reply to Jason Plum from comment #31) > At least here, not quite. Dialogs behave as expected. Final windo still on > non-primary display, though geometry is more accurate to the size of the > display the mouse is/was on, it is not on the correct (primary) display. That's with attachment 6682 alone applied, not with any of the previous patches, right? This is weird, it behaves correctly here...
Yes, only your last attachment.
Do you have your Primary display set to the left-most?
(In reply to Jason Plum from comment #34) > Do you have your Primary display set to the left-most? Yeap, tried with all sort of different resolutions, layouts, etc. it worked fine in all cases here...
What method might I be able to use to show you the state of this system where the problem is occurring?
Created attachment 6691 Updated patch with logs Can you try the following: 1. Start from a clean, un-patched, freshly downloaded source tree 2. Apply the (new) patch attached and rebuild 3. From the source tree, re-start the new xfwm4 with: ./src/xfwm4 --replace & 4. Reproduce the issue and attach the messages that xfwm4 will print on the terminal
On which branch of the source tree? Currently I have been patching with modification to : https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/xfwm4 Getting the source tarball from http://archive.xfce.org/src/xfce/xfwm4/4.12/xfwm4-4.12.3.tar.bz2)
Success! This does indeed appear to apply & Fix the issue.
Patch pushed to git, closing.