bug#25542: 25.1; Restoring the frame from fullscreen to maximized

[Ken Brown <kbrown@cornell.edu>]

[-- Attachment #1: Type: text/plain, Size: 2458 bytes --]

On 9/11/2020 3:53 AM, martin rudalics wrote:
>  >> ... after
>  >> maximizing the frame with the mouse, the value of
>  >>
>  >> (frame-parameter nil 'fullscreen)
>  >>
>  >> is nil.  Correct?
>  >
>  > Yes.
>  >
>  >> And what is its value if, instead, you maximize the
>  >> frame via 'toggle-frame-maximized'?
>  >
>  > maximized.
> 
> Mixing frame resizing triggered by Emacs commands and external tools is
> tricky to handle.
> 
>  >> Apparently some check _is_ needed (why?) so probably
>  >> using
>  >>
>  >>              if (x < 0 || y < 0)
>  >>                store_frame_param (f, Qfullscreen, Qmaximized);
>  >>
>  >> instead will fix it.  Can you try that (as I said elsewhere it will then
>  >> fail for borderless, maximized frames)?
>  >
>  > Yes, that does fix it.
> 
> So we'll probably have to use that.  Can you install it?

Patch attached (under your name).  Please check it and see if the commit message 
and comment change are OK.

Eli and Lars, I think this should go to master rather than the emacs-27 branch, 
since there's too much that we don't understand about the fix.  Do you agree?

>  > I haven't tried to test anything involving borderless frames.
> 
> If you
> 
> (set-frame-parameter nil 'undecorated t)
> 
> and maximize the frame via some Windows (Aero, IIRC) command, what does

Sorry, but I don't know what an Aero command is, and I'm not interested in 
learning if I don't have to.  If anyone really cares about this case and can't 
carry out the experiment themselves, I'm willing to do it, but I'll need 
explicit instructions.

> (frame-parameter nil 'fullscreen)
> 
> report?  With and without the && ~> || change.
> 
> And it would still be interesting to understand your earlier finding,
> namely that
> 
>    If I make this change and follow Dani's recipe from the original bug
>    report, the second F11 press doesn't restore the previous state.
>    Instead, the frame appears to get slightly smaller for an instant and
>    then immediately reverts to fullscreen mode.
> 
> That second F11 should set the 'fullscreen parameter to 'maximized so I
> fail to see how a subsequent action can restore it to 'fullboth.  In
> retrospect, that
> 
>            /* Windows can send us a SIZE_MAXIMIZED message even
>               when fullscreen is fullboth ....
> 
> comment apparently matches your experience now but I cannot even recall
> based on what experience I added it back then.
> 
> Thanks, martin

Ken

[-- Attachment #2: 0001-Fix-toggle-frame-fullscreen-on-w32-builds.patch --]
[-- Type: text/plain, Size: 1320 bytes --]

From 9dd0fe7a16fba2b37e79be24acbd325b159086c6 Mon Sep 17 00:00:00 2001
From: Martin Rudalics <rudalics@gmx.at>
Date: Fri, 11 Sep 2020 16:04:20 -0400
Subject: [PATCH] Fix toggle-frame-fullscreen on w32 builds

* src/w32term.c (w32_read_socket): Set 'fullscreen' to 'maximized'
if Windows sends SIZE_MAXIMIZED and either the top or the left of
the frame is outside the screen.  (Bug#25542)
---
 src/w32term.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/w32term.c b/src/w32term.c
index 1766b32514..2669f29b56 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -5478,15 +5478,15 @@ w32_read_socket (struct terminal *terminal,
 		  /* Windows can send us a SIZE_MAXIMIZED message even
 		     when fullscreen is fullboth.  The following is a
 		     simple hack to check that based on the fact that
-		     only a maximized fullscreen frame should have both
-		     top/left outside the screen.  */
+		     only a maximized fullscreen frame should have top
+		     or left outside the screen.  */
 		  if (EQ (fullscreen, Qfullwidth) || EQ (fullscreen, Qfullheight)
 		      || NILP (fullscreen))
 		      {
 			int x, y;
 
 			w32_real_positions (f, &x, &y);
-			if (x < 0 && y < 0)
+			if (x < 0 || y < 0)
 			  store_frame_param (f, Qfullscreen, Qmaximized);
 		      }
 		  }
-- 
2.28.0