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

[Ken Brown <kbrown@cornell.edu>]

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