Bug 92653

I am also seeing this issue after upgrading to El Capitan.  I was running the same version of XQuartz, 2.7.8, on Yosemite before upgrading to El Capitan.  After upgrading to El Capitan, I re-ran the XQuartz installer.  My machine is a 2012 15" MacBook Pro, and when I come into the office I attach an external 1920x1080 display which is arranged to the left of the laptop display, and I use it as my primary display.  I normally run with "Displays have separate Spaces", but the issue also happens when that is unchecked.

The only windows that are affected are windows that have not been moved since they were created.

If I run "xwininfo" before and after, what I notice is that the Absolute upper-left X and Absolute Upper-left X values have doubled:

Before:
  Absolute upper-left X:  760
  Absolute upper-left Y:  22
After:
  Absolute upper-left X:  1520
  Absolute upper-left Y:  44

And another example:
Before:
  Absolute upper-left X:  123
  Absolute upper-left Y:  256
After:
  Absolute upper-left X:  246
  Absolute upper-left Y:  512

So it is very consistent, the absolute x-y coordinates are being doubled.

This only happens when the windows haven't been manually moved or resized from their original locations.  The conditions under which this happens for me are:

1) Start up xterms without the external display attached, then plug in the external display.
2) Start up the xterms with the external display attached, then put the laptop to sleep and wake it up.
3) Start up the xterms with the external display attached, put the laptop to sleep, unplug the external display, then wake up the laptop.

For cases 2 and 3, if after starting up the xterms I unplug and plug back in the external display, then the windows do not jump after the sleep/wakeup.  Or if I just unplug the external display before putting it to sleep, then the windows do not jump.

The only other variant is that in case #3, the windows that would have jumped off the screen to the right are instead moved to the upper left corner of the display.

(In reply to David Borman from comment #1)
> ... My
> machine is a 2012 15" MacBook Pro

It shouldn't matter, but it's a non-retina, with the 1680-by-1050 high-resolution antiglare display.

I've also reproduced the issue without any external display:

1) Start up X11, and open some xterm windows
2) Do not move the windows from their initial location.
3) Put the machine to sleep
4) Wake the machine back up.

I have my external display configured to be my main screen, to the left of my laptop screen.

Have you reproduced this issue?  If not, what additional information can I give you to help you reproduce it?  I'd really like to have this fixed.

Rearrangement of the windows upon display reconfiguration has been an issue for as long as I've known.  However, I have not seen this issue when sleeping, and I don't think there is anything specific about El Capitan involved here.

it started when i moved to el capitan.  it is irrespective of external
monitor.  it is VERY annoying.

Here's a clean test that I just ran that exhibits the problem:

1) Install El Capitan on a new disk
   - Don't restore anything
   - Just create a single new account
2) Boot up the fresh install and log in
   - Don't connect to iCloud or anything
3) Install XQuartz 2.7.8
4) Log out and back in
5) Double click the XQuartz app to start X11
6) In the default xterm window, run the command:
    xterm -geometry 80x60+600+20 &
7) Put the computer to sleep from the Apple->Sleep menu
8) Wake it up, and the window had jumped.

OSX version: 10.11.1
XQuartz version: 2.7.8
Hardware: 2012 non-retina MacBook Pro, 1680-by-1050 high-resolution display, 16G memory

So this test eliminates any local configuration issues.  It is just a stock El Capitan install with a stock XQuartz 2.7.8 install.

Here's the before and after output of xwininfo.  Notice how the XY values for the upper left corner have doubled.

% xwininfo

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0xe0000d "xterm"

  Absolute upper-left X:  600
  Absolute upper-left Y:  42
  Relative upper-left X:  0
  Relative upper-left Y:  22
  Width: 579
  Height: 844
  Depth: 24
  Visual: 0x22
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x21 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +600+42  -501+42  -501-142  +600-142
  -geometry 80x60+600+20

% xwininfo

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0xe0000d "xterm"

  Absolute upper-left X:  1200
  Absolute upper-left Y:  84
  Relative upper-left X:  0
  Relative upper-left Y:  22
  Width: 579
  Height: 844
  Depth: 24
  Visual: 0x22
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x21 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +1200+84  --99+84  --99-100  +1200-100
  -geometry 80x60--99+62

I've run some more tests.  I changed my configuration to use twm instead of quartz-wm, and when running with twm I do not see the problem of jumping windows.  For another test I also ran X11 without any window manager, and putting the machine to sleep and waking it back up did not cause the windows to jump.  I went back to quartz-wm and the problem of jumping windows came back.

I built a debug version of quartz-wm with some additional traces to see what type of events are happening.  After the sleep/wakeup, a snippet of what I see:

1/28/16 4:26:22.883 PM quartz-wm[84937]: TRACE: id: 0x140000d frame_id: 0x1000013
1/28/16 4:26:22.883 PM quartz-wm[84937]: TRACE
1/28/16 4:26:22.883 PM quartz-wm[84937]:         win_rect: 20,30 299x306
1/28/16 4:26:22.883 PM quartz-wm[84937]:         dock_rect: 0,1054 1920x4
1/28/16 4:26:22.883 PM quartz-wm[84937]:         screen_rect: 0,0 3600x1058
1/28/16 4:26:22.883 PM quartz-wm[84937]:         screen_no_dock: 0,0 3600x1054
1/28/16 4:26:22.883 PM quartz-wm[84937]:         title_rect: 20,30 299x22
1/28/16 4:26:22.883 PM quartz-wm[84937]:         title_int_rect: 20,30 299x22
1/28/16 4:26:22.883 PM quartz-wm[84937]:         win_int_rect: 20,30 299x306
1/28/16 4:26:22.883 PM quartz-wm[84937]:         ret: 20,30 299x306
1/28/16 4:26:22.883 PM quartz-wm[84937]: validate_position(): 20,30 ok
1/28/16 4:26:22.883 PM quartz-wm[84937]: END: <ConfigureNotify window:1a1>
1/28/16 4:26:22.883 PM quartz-wm[84937]: START: <ConfigureNotify window:1a1>
1/28/16 4:26:22.883 PM quartz-wm[84937]: x_event_configure_notify() send_event:0 event:1a1 window:1000013 x,y:40,82 w,h:299,306 bw:0 above:1400012 override:1

The first part is the tail end of a ConfigureNotify that lists all the windows, including the window that I started up at 20,30.  Right after that, another ConfigureNotify event arrives for that same window, this time at 40,82.  The X coordinate had doubled, and the Y coordinate has also doubled, plus 22 for the menu bar added to the top of the window.

So, the evidence seems to be that quartz-wm is being told of a new location for the window, it isn't originating the move.

What has always intrigued me is that the window jumping isn't random, it is a doubling of the X,Y coordinates, plus the height of the menu bar added to the top of the window.

And a difference of 2X makes me think about Retina displays.  Maybe there's a bit of code somewhere that is supposed to deal with Retina displays that is doing the wrong thing, and doubling the coordinates when it shouldn't, or not undoubling them when it should.  For another experiment, I booted up my virgin El Capitan/XQuartz-2.7.8 disk on a colleagues Retina MacBook Pro, but it exhibited the same window jumping across a sleep.

*** Bug 94579 has been marked as a duplicate of this bug. ***

this bug is now a year old.  it is very very painful, 20-30 minutes to get al my desktops of xterms back and happy on restart.  it has continued through to el capitan and xquartz 2.79. would it help to offer a bounty?

(In reply to Randy Bush from comment #8)
> this bug is now a year old.  it is very very painful, 20-30 minutes to get
> al my desktops of xterms back and happy on restart.  it has continued
> through to el capitan and xquartz 2.79. would it help to offer a bounty?

For what it's worth, I haven't had this happen at all since upgrading to Sierra.

> For what it's worth, I haven't had this happen at all since upgrading to
> Sierra.

ok.  finally a reason to go to sierra.  thanks.

(In reply to Randy Bush from comment #10)
> > For what it's worth, I haven't had this happen at all since upgrading to
> > Sierra.
> 
> ok.  finally a reason to go to sierra.  thanks.

Really! Great news to hear!

I'm still waiting for one 3rd app to be updated for Sierra, and I'm looking forward to see if it's really fixed.

> I'm still waiting for one 3rd app to be updated for Sierra, and I'm looking
> forward to see if it's really fixed.

I am assuming that the problem has been fixed, since my original bug report (see https://bugs.freedesktop.org/show_bug.cgi?id=94579) was marked as aduplicate of this one.

That problem has completely disappeared, and I have even reenabled "displays have separate spaces" with no issues.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.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.freedesktop.org/xorg/app/quartz-wm/issues/1.