Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)

From: [email-masked] (Charles A. Roelli)
Date: Sun, 19 Mar 2017 20:38:50 +0100

Hi again,

Sorry for taking a while to get back on this.

Looking at this issue again, it would be helpful to know what version of
OS X you use and whether you see the issue that I described in the first
message of this thread (*), and also whether the patch I suggested stops
frames from being placed above the top of the screen.  Because from what
I can see, I don't see how the patch will prevent you from doing so,
unless you have "Spaces" turned off.

(*) One quick way of finding out is running something like
    `(set-frame-position (selected-frame) 0 10000)' (best done from
    `emacs -Q').  If the moved frame cannot be returned on-screen
    programmatically, then you have the issue.  If it stays on-screen,
    then you don't.

My patch got rid of these lines:

-#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_9
-  // If separate spaces is on, it is like each screen is independent.  There is
-  // no spanning of frames across screens.
-  if ([NSScreen screensHaveSeparateSpaces])
-    {
-      NSTRACE_MSG ("Screens have separate spaces");
-      frameRect = [super constrainFrameRect:frameRect toScreen:screen];
-      NSTRACE_RETURN_RECT (frameRect);
-      return frameRect;
-    }
-#endif

According to the Apple documentation, screensHaveSeparateSpaces()
"returns a Boolean value that indicates whether each screen can have its
own set of spaces.  This method reflects whether the “Displays have
separate Spaces” option is enabled in Mission Control system
preference. You might use the return value to determine how to present
your app when in fullscreen mode."

So the idea of this code was to constrain a frame only if "Spaces" is
enabled, right?  I assume then, that if you have "Spaces" turned on (but
even if you don't necessarily use the feature), then frames are
prevented from going entirely off-screen (which is a must for OS X).

The reason I ask this is because I have no idea whether the problem
exists in Emacs on newer versions of OS X.  If it doesn't, then the fix
can be added only for OS X < 10.9.