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

[Ken Brown]

On 9/5/2020 12:07 PM, Eli Zaretskii wrote:
> > Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>, 25542@debbugs.gnu.org,
> >   Noam Postavsky <npostavs@users.sourceforge.net>,
> >   martin rudalics <rudalics@gmx.at>
> > From: Ken Brown <kbrown@cornell.edu>
> > Date: Sat, 5 Sep 2020 11:10:31 -0400
> >
> > diff --git a/src/w32term.c b/src/w32term.c
> > index 76cf6bd696..c7da95528b 100644
> > --- a/src/w32term.c
> > +++ b/src/w32term.c
> > @@ -5454,15 +5454,7 @@ w32_read_socket (struct terminal *terminal,
> >                        simple hack to check that based on the fact that
> >                        only a maximized fullscreen frame should have both
> >                        top/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)
> > -                         store_frame_param (f, Qfullscreen, Qmaximized);
> > -                     }
> > +                   store_frame_param (f, Qfullscreen, Qmaximized);
> >                     }
> >
> >                     break;
> >
> > 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.
>
> Thanks for testing.  It sounds like the proposed change leaves the
> original incorrect behavior unchanged, so we need to look for some
> different way of fixing this.

It's not unchanged, it's just wrong in a different way.  Previously the second 
F11 resulted in an unmaximized frame.

Ken