I have a multiple monitor setup as follows: $ xrandr --listmonitors Monitors: 3 0: +*DisplayPort-0 1920/518x1200/324+1080+480 DisplayPort-0 1: +HDMI-A-0 1080/527x1920/297+0+284 HDMI-A-0 2: +DVI-D-0 1050/408x1680/306+3000+0 DVI-D-0 It seems there are a couple of prerequisites required to trigger this bug: - You need an application that supports dragging tab's to new window's. I use Chromium as an example. - Chromium needs to have a default position on e.g. mon2 (as in when you click the application launcher it opens on mon2). - Not fully sure about this yet, but it could be that the default position should also be in a maximised state (as after clicking on the applicatoin launcher it opens maximised on mon2) - Then drag Chromium to the top of mon0 to maximize it on mon0 - Make sure Chromium has at least two tabs, so one Chromium window with 2 tabs Now when you drag one of the tabs away (so you have 2 windows each with 1 tab), the new window is positioned on mon2 instead of mon0. This results in a confusing experience because your mouse is still on mon0 and there is an offset between your mouse movements and the movements of your new window. Maybe the following observation is related. If instead you drag the whole window (so instead of one tab to create a new window you drag the window with 2 tabs) the window loses its maximised state and returns to its original size under the current mouse position on mon0. But for a very brief moment just after dragging the window from the top of mon0 the window is positioned on mon2 as well (before being placed on mon0). This behaviour is not always visible as this happens really quick (eg you will only see a quick flickering on mon2). Currently I am looking at clientInitPosition as the possible culprit, but I will have to add some more debug information first and will come back on this.
It seems the problem is that XGetWindowAttributes from libX11 returns the stored size/position of the window before maximising. As I am not sure what the supposed behaviour of XGetWindowAttributes should be, is this an upstream bug or should we fix this in clientFrame?
(In reply to Pim Pronk from comment #1) > It seems the problem is that XGetWindowAttributes from libX11 returns the > stored size/position of the window before maximising. > > As I am not sure what the supposed behaviour of XGetWindowAttributes should > be, is this an upstream bug or should we fix this in clientFrame? XGetWindowAttributes() returns whatever the clients set as XWindowAttributes which includes the location, so if the clients set a given location, iot gets that location. Sounds like a bug in the client to me.
After looking at XGetWindowAttributes in libX11/src/GetWAttrs.c it seems the current location is requested from the xserver. It calls GetGeometry defined in xserver/dix/dispatch.c which returns the origin.x,y of the window. When I run 'xwininfo -tree -id <id_of_root>' just before dragging the tab, it doesnt list any windows that are located on mon2. I am not sure how the mechanism works to drag a tab to a window, but the first time I see the new window in a trace is when compositorHandleCreateNotify is called. But as I have disabled the compositor, it proceeds to handleMapRequest and there ev->window already has the wrong position on mon2. Also after more checking, this bug only happens when Chromium starts maximised. It doesnt happen when it starts not-maximised, then maximised etc. It also doesnt happen when it starts maximised, then drag to not-maximised then maximise it. Could this be a bug in Chromium? As after checking other applications it seems Chromium is also the only one that remembers its last position.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/245. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev