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

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

[Dani Moncayo]

Recipe from "emacs -Q"

1. Maximize the frame using the mouse -- for example, on MS-Windows,
either click on the "maximize" button or double click on the title
bar.

2. Switch to fullscreen by pressing F11.

3. Press F11 again.


Expected behavior: The frame goes to its previous state (i.e. maximized).

Observed behavior: The frame is not maximized (it is smaller that a
maximized one, both in height and width).


I'm using the Emacs distributed with cygwin, which uses the native
MS-Windows GUI (package "emacs-w32"):

In GNU Emacs 25.1.1 (x86_64-unknown-cygwin)
 of 2016-09-17 built on desktop-new
Windowing system distributor 'Microsoft Corp.', version 10.0.10586
Configured using:
 'configure
 --srcdir=/home/kbrown/src/cygemacs/emacs-25.1-1.x86_64/src/emacs-25.1
 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
 --docdir=/usr/share/doc/emacs --htmldir=/usr/share/doc/emacs/html -C
 --with-w32 'CFLAGS=-ggdb -O2 -pipe -Wimplicit-function-declaration
 -fdebug-prefix-map=/home/kbrown/src/cygemacs/emacs-25.1-1.x86_64/build=/usr/src/debug/emacs-25.1-1
 -fdebug-prefix-map=/home/kbrown/src/cygemacs/emacs-25.1-1.x86_64/src/emacs-25.1=/usr/src/debug/emacs-25.1-1'
 CPPFLAGS= LDFLAGS='

Configured features:
XPM JPEG TIFF GIF PNG IMAGEMAGICK SOUND DBUS NOTIFY ACL GNUTLS LIBXML2
ZLIB TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

-- 
Dani Moncayo

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

[martin rudalics]

 > Recipe from "emacs -Q"
 >
 > 1. Maximize the frame using the mouse -- for example, on MS-Windows,
 > either click on the "maximize" button or double click on the title
 > bar.
 >
 > 2. Switch to fullscreen by pressing F11.
 >
 > 3. Press F11 again.
 >
 >
 > Expected behavior: The frame goes to its previous state (i.e. maximized).

This is the behavior I get with my MinGW builds on Windows XP.

 > Observed behavior: The frame is not maximized (it is smaller that a
 > maximized one, both in height and width).
 >
 >
 > I'm using the Emacs distributed with cygwin, which uses the native
 > MS-Windows GUI (package "emacs-w32"):

What is that package "emacs-w32"?

martin

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

[Dani Moncayo]

>> I'm using the Emacs distributed with cygwin, which uses the native
>> MS-Windows GUI (package "emacs-w32"):
>
> What is that package "emacs-w32"?

I'm not sure I understand your question, so my answer may be
trivial/useless to you, but anyway:  Cygwin is a distribution of
software organized in packages.  The name of one of those packages is
"emacs-w32" (you can search for it in the cygwin package manager).
Well, that is the package which includes the Emacs binary I'm using.
It's basically a build of Emacs made for the Cygwin platform, but
modified to use the native MS-Windows GUI, instead of X-Window or
another toolkit like GTK+.

HTH.

-- 
Dani Moncayo

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

[Dani Moncayo]

BTW, I forgot to mention that my OS (on which Cygwin is installed) is
MS-Windows 10 Enterprise.

-- 
Dani Moncayo

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

[Dani Moncayo]

Hello,

I've just realized another detail required to reproduce the problem:
the Windows taskbar must be docked to the left side of the screen.
(If I move the taskbar to the bottom side --its default position--,
then I cannot reproduce the problem).

I've just reproduced the problem also with a native MS-Windows build
of Emacs (a recent build from the emacs-25 branch):

  In GNU Emacs 25.1.90.1 (i686-pc-mingw32)
   of 2016-12-28 built on LEG570
  Repository revision: 697167b5432a89db009238cf5cbddc61e69ad339
  Windowing system distributor 'Microsoft Corp.', version 10.0.14393
  Configured using:
   'configure --host=i686-pc-mingw32'

-- 
Dani Moncayo

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

[Noam Postavsky]

On Thu, Jan 26, 2017 at 12:49 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
> Hello,
>
> I've just realized another detail required to reproduce the problem:
> the Windows taskbar must be docked to the left side of the screen.
> (If I move the taskbar to the bottom side --its default position--,
> then I cannot reproduce the problem).
>
> I've just reproduced the problem also with a native MS-Windows build
> of Emacs (a recent build from the emacs-25 branch):

I can confirm with 25.1 and master. Oddly enough, having the taskbar
on the *right* side of screen (which I usually do) doesn't trigger
this issue either.

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

[martin rudalics]

 > I've just realized another detail required to reproduce the problem:
 > the Windows taskbar must be docked to the left side of the screen.
 > (If I move the taskbar to the bottom side --its default position--,
 > then I cannot reproduce the problem).
 >
 > I've just reproduced the problem also with a native MS-Windows build
 > of Emacs (a recent build from the emacs-25 branch):

What does M-: (w32-display-monitor-attributes-list) return when your
taskbar is on the left?

Do other applications handle your scenario correctly?  Firefox?

martin

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

[Dani Moncayo]

Hi Martin,

> What does M-: (w32-display-monitor-attributes-list) return when your
> taskbar is on the left?

(((geometry 0 0 1600 900) (workarea 62 0 1538 900) (mm-size 443 249)
(name . "\\\\.\\DISPLAY1") (frames #<frame emacs@CPX-L6Q03C31DOX
0x10100bc30>)))

> Do other applications handle your scenario correctly?  Firefox?

I've just tested the chrome browser, and the File Explorer.  Both
behave correctly.

-- 
Dani Moncayo

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

[martin rudalics]

 >> What does M-: (w32-display-monitor-attributes-list) return when your
 >> taskbar is on the left?
 >
 > (((geometry 0 0 1600 900) (workarea 62 0 1538 900) (mm-size 443 249)
 > (name . "\\\\.\\DISPLAY1") (frames #<frame emacs@CPX-L6Q03C31DOX
 > 0x10100bc30>)))

So the taskbar is recognized correctly.

Thanks, martin

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

[martin rudalics]

 >> What is that package "emacs-w32"?
 >
 > I'm not sure I understand your question, so my answer may be
 > trivial/useless to you, but anyway:  Cygwin is a distribution of
 > software organized in packages.  The name of one of those packages is
 > "emacs-w32" (you can search for it in the cygwin package manager).
 > Well, that is the package which includes the Emacs binary I'm using.

I don't have Cygwin installed so I doubt that using its package manager
would make much sense for me.  Anyway, I suppose it provides a w32
executable, say emacs-w32.exe and some additional libraries.  I was a
bit confused by the term "package".

 > It's basically a build of Emacs made for the Cygwin platform, but
 > modified to use the native MS-Windows GUI, instead of X-Window or
 > another toolkit like GTK+.

We would probably have to look at these "modifications" in order to find
out what happens.  Meanwhile a few questions:

(1) What is the appearance of the maximize button after step 3?  Does it
     show two overlapping windows or one large window?

(2) How do the frames from before step 2 and after step 3 differ?
     Please use M-: (frame-geometry) and post the ‘outer-position’ and
     ‘outer-size’ values.

(3) Apart from the problem you reported do

     M-: (set-frame-parameter nil 'fullscreen 'maximized)

     and clicking on the maximize button of the title bar produce frames
     with the same size and position?

(4) Does setting ‘frame-resize-pixelwise’ to t change anything?

(5) Can you try with a native Windows build or a GTK build and see
     whether they exhibit the same problem?

 > BTW, I forgot to mention that my OS (on which Cygwin is installed) is
 > MS-Windows 10 Enterprise.

Can anyone with a native build on Windows 10 reproduce the problem?

Thanks, martin

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

[Noam Postavsky]

On Thu, Jan 26, 2017 at 9:00 AM, martin rudalics <rudalics@gmx.at> wrote:
>
>> BTW, I forgot to mention that my OS (on which Cygwin is installed) is
>> MS-Windows 10 Enterprise.
>
> Can anyone with a native build on Windows 10 reproduce the problem?

Does not reproduce for me on Windows 10 using the native 25.1 release
or master from a few days ago.

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

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Thu, 26 Jan 2017 10:43:29 -0500
> Cc: 25542@debbugs.gnu.org
> 
> On Thu, Jan 26, 2017 at 9:00 AM, martin rudalics <rudalics@gmx.at> wrote:
> >
> >> BTW, I forgot to mention that my OS (on which Cygwin is installed) is
> >> MS-Windows 10 Enterprise.
> >
> > Can anyone with a native build on Windows 10 reproduce the problem?
> 
> Does not reproduce for me on Windows 10 using the native 25.1 release
> or master from a few days ago.

That's strange, since the Cygwin w32 build is supposed to use the same
code as the native build for its GUI display backend.

Maybe Dani could test a native build on the same system?

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

[Dani Moncayo]

> (1) What is the appearance of the maximize button after step 3?  Does it
>     show two overlapping windows or one large window?

The button shows a single box.- i.e., the window state is _not_ maximized.

> (2) How do the frames from before step 2 and after step 3 differ?
>     Please use M-: (frame-geometry) and post the ‘outer-position’ and
>     ‘outer-size’ values.

The frames are exactly equal.  Both in size and positon on the screen.

> (3) Apart from the problem you reported do
>
>     M-: (set-frame-parameter nil 'fullscreen 'maximized)
>
>     and clicking on the maximize button of the title bar produce frames
>     with the same size and position?

Yes.  Both are maximized frames, which take up the entire screen
except the taskbar.

> (4) Does setting ‘frame-resize-pixelwise’ to t change anything?

No (the problem persists after setting that variable to t).

> (5) Can you try with a native Windows build or a GTK build and see
>     whether they exhibit the same problem?

This was answered in a previous mail.  The problem is reproducible
also with a native windows build.

-- 
Dani Moncayo

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

[Eli Zaretskii]

> From: Dani Moncayo <dmoncayo@gmail.com>
> Date: Fri, 27 Jan 2017 09:03:41 +0100
> Cc: 25542@debbugs.gnu.org
> 
> > (2) How do the frames from before step 2 and after step 3 differ?
> >     Please use M-: (frame-geometry) and post the ‘outer-position’ and
> >     ‘outer-size’ values.
> 
> The frames are exactly equal.  Both in size and positon on the screen.

This seems to contradict your original report, where you said the two
frames had different sizes.  Or maybe you are saying that the above 2
functions return the same values, but the actual values are different?

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

[Dani Moncayo]

>> > (2) How do the frames from before step 2 and after step 3 differ?
>> >     Please use M-: (frame-geometry) and post the ‘outer-position’ and
>> >     ‘outer-size’ values.
>>
>> The frames are exactly equal.  Both in size and positon on the screen.
>
> This seems to contradict your original report, where you said the two
> frames had different sizes.

Mmmm I said this:

  Observed behavior: The frame is not maximized (it is smaller that a
  maximized one, both in height and width).

So I don't see any contradiction - What I wanted to express in both
cases is that the Emacs frame, after the final step, is _not_
maximized (as it should be).

IOW: in step 3, the frame should have been switched from fullscreen to
maximized, but it actually switched to the initial status/size (i.e.
not maximized).

HTH

-- 
Dani Moncayo

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

[martin rudalics]

 >> (1) What is the appearance of the maximize button after step 3?  Does it
 >>      show two overlapping windows or one large window?
 >
 > The button shows a single box.- i.e., the window state is _not_ maximized.

This should not happen.  Does it show the two boxes after step 3 with
the taskbar placed on any of the three other sides of your screen?

 >> (2) How do the frames from before step 2 and after step 3 differ?
 >>      Please use M-: (frame-geometry) and post the ‘outer-position’ and
 >>      ‘outer-size’ values.
 >
 > The frames are exactly equal.  Both in size and positon on the screen.

Please post the values, maybe they can give us a clue.

Thanks, martin

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

[Dani Moncayo]

On Fri, Jan 27, 2017 at 10:19 AM, martin rudalics <rudalics@gmx.at> wrote:
>>> (1) What is the appearance of the maximize button after step 3?  Does it
>>>      show two overlapping windows or one large window?
>>
>> The button shows a single box.- i.e., the window state is _not_ maximized.
>
> This should not happen.  Does it show the two boxes after step 3 with
> the taskbar placed on any of the three other sides of your screen?

I've just tried with the taskbar on the bottom side, and yes, it does
show the two boxes (i.e., maximized frame, expected behavior).

>>> (2) How do the frames from before step 2 and after step 3 differ?
>>>      Please use M-: (frame-geometry) and post the ‘outer-position’ and
>>>      ‘outer-size’ values.
>>
>> The frames are exactly equal.  Both in size and positon on the screen.
>
> Please post the values, maybe they can give us a clue.

In both cases (before step 2 and after step 3), (frame-geometry) outputs this:

  ((outer-position 192 . 130) (outer-size 689 . 671)
(external-border-size 8 . 8) (title-bar-size 651 . 23)
(menu-bar-external . t) (menu-bar-size 673 . 20) (tool-bar-external)
(tool-bar-position . top) (tool-bar-size 689 . 36)
(internal-border-width . 0))


-- 
Dani Moncayo

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

[Dani Moncayo]

BTW/FWIW: I've now tried to reproduce the problem with the taskbar
placed at every possible side (left, right, top, bottom).  I see the
problem with the taskbar in the left or top.  I do _not_ see the
problem with the taskbar in the bottom or right.

HTH

-- 
Dani Moncayo

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

[martin rudalics]

 > BTW/FWIW: I've now tried to reproduce the problem with the taskbar
 > placed at every possible side (left, right, top, bottom).  I see the
 > problem with the taskbar in the left or top.  I do _not_ see the
 > problem with the taskbar in the bottom or right.

That sounds at least consistent.  Please post also the ‘frame-geometry’
figures for all three cases and `w32-display-monitor-attributes-list' to
know the height of the taskbar when it's at bottom/top.

martin

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

[Dani Moncayo]

> Please post also the ‘frame-geometry’
> figures for all three cases and `w32-display-monitor-attributes-list' to
> know the height of the taskbar when it's at bottom/top.

OK, here is the ouput of (frame-geometry) when the Emacs frame is
maximized, for each possible position of the taskbar:

TOP:
((outer-position -8 . 22) (outer-size 1616 . 886)
(external-border-size 8 . 8) (title-bar-size 1578 . 23)
(menu-bar-external . t) (menu-bar-size 1600 . 20) (tool-bar-external)
(tool-bar-position . top) (tool-bar-size 1616 . 36)
(internal-border-width . 0))

RIGHT:
((outer-position -8 . -8) (outer-size 1554 . 916)
(external-border-size 8 . 8) (title-bar-size 1516 . 23)
(menu-bar-external . t) (menu-bar-size 1538 . 20) (tool-bar-external)
(tool-bar-position . top) (tool-bar-size 1554 . 36)
(internal-border-width . 0))

BOTTOM:
((outer-position -8 . -8) (outer-size 1616 . 886)
(external-border-size 8 . 8) (title-bar-size 1578 . 23)
(menu-bar-external . t) (menu-bar-size 1600 . 20) (tool-bar-external)
(tool-bar-position . top) (tool-bar-size 1616 . 36)
(internal-border-width . 0))

LEFT:
((outer-position 54 . -8) (outer-size 1554 . 916)
(external-border-size 8 . 8) (title-bar-size 1516 . 23)
(menu-bar-external . t) (menu-bar-size 1538 . 20) (tool-bar-external)
(tool-bar-position . top) (tool-bar-size 1554 . 36)
(internal-border-width . 0))



-- 
Dani Moncayo

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

[Dani Moncayo]

> OK, here is the ouput of (frame-geometry) when the Emacs frame is
> maximized, for each possible position of the taskbar:

And here is the output of (w32-display-monitor-attributes-list) in
those same cases:

TOP:
(((geometry 0 0 1600 900) (workarea 0 30 1600 870) (mm-size 443 249)
(name . "\\\\.\\DISPLAY1") (frames #<frame emacs@CPX-L6Q03C31DOX
0x10100bc30>)))

RIGHT:
(((geometry 0 0 1600 900) (workarea 0 0 1538 900) (mm-size 443 249)
(name . "\\\\.\\DISPLAY1") (frames #<frame emacs@CPX-L6Q03C31DOX
0x10100bc30>)))

BOTTOM:
(((geometry 0 0 1600 900) (workarea 0 0 1600 870) (mm-size 443 249)
(name . "\\\\.\\DISPLAY1") (frames #<frame emacs@CPX-L6Q03C31DOX
0x10100bc30>)))

LEFT:
(((geometry 0 0 1600 900) (workarea 62 0 1538 900) (mm-size 443 249)
(name . "\\\\.\\DISPLAY1") (frames #<frame emacs@CPX-L6Q03C31DOX
0x10100bc30>)))

-- 
Dani Moncayo

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

[martin rudalics]

 > I've just tried with the taskbar on the bottom side, and yes, it does
 > show the two boxes (i.e., maximized frame, expected behavior).

Can you try the other two sides as well?

 > In both cases (before step 2 and after step 3), (frame-geometry) outputs this:
 >
 >    ((outer-position 192 . 130)

This completely contradicts what I have seen till now: outer-position
should be negative on at least one side (in your case the value 130
should be something like -4 accounting for the external border width).

What's even more strange is that it shows this value before step 2.
This seems to indicate that the frame was not maximized before step 2
either.  What are the respective values with the taskbar on bottom?

 > (outer-size 689 . 671)

Is it true that your screen is almost square and has so few pixels?

martin

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

[Dani Moncayo]

>> In both cases (before step 2 and after step 3), (frame-geometry) outputs
>> this:
>>
>>    ((outer-position 192 . 130)

I'm afraid I've been imprecise here.  I was comparing the initial and
final scenarios (i.e. before step 1 and after step 3).

So, I'll now post the values you wanted:

** Before step 2 (i.e. just after maximizing the frame with the mouse):

((outer-position 54 . -8) (outer-size 1554 . 916)
(external-border-size 8 . 8) (title-bar-size 1516 . 23)
(menu-bar-external . t) (menu-bar-size 1538 . 20) (tool-bar-external)
(tool-bar-position . top) (tool-bar-size 1554 . 36)
(internal-border-width . 0))

** After step 3 (i.e. just after pressing F11 a second time)

((outer-position 192 . 130) (outer-size 689 . 671)
(external-border-size 8 . 8) (title-bar-size 651 . 23)
(menu-bar-external . t) (menu-bar-size 673 . 20) (tool-bar-external)
(tool-bar-position . top) (tool-bar-size 689 . 36)
(internal-border-width . 0))

These values (after final step) are the same I get at the very
beginning (just after "emacs -Q").

Sorry for the confusion.

>> (outer-size 689 . 671)
>
> Is it true that your screen is almost square and has so few pixels?

No, my screen resolution is 1600 x 900 pixels.

-- 
Dani Moncayo

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

[martin rudalics]

 > ** Before step 2 (i.e. just after maximizing the frame with the mouse):
 >
 > ((outer-position 54 . -8) (outer-size 1554 . 916)

54 because the frame's left outer edge is by external-border-size
pixels left of the taskbar's right end which according to

 > LEFT:
 > (((geometry 0 0 1600 900) (workarea 62 0 1538 900) (mm-size 443 249)
 > (name . "\\\\.\\DISPLAY1") (frames #<frame emacs@CPX-L6Q03C31DOX
 > 0x10100bc30>)))

is at 62.  -8 because the frame's top edge is by external-border-size
pixels above the display.

 > (external-border-size 8 . 8) (title-bar-size 1516 . 23)
 > (menu-bar-external . t) (menu-bar-size 1538 . 20) (tool-bar-external)
 > (tool-bar-position . top) (tool-bar-size 1554 . 36)
 > (internal-border-width . 0))
 >
 > ** After step 3 (i.e. just after pressing F11 a second time)
 >
 > ((outer-position 192 . 130) (outer-size 689 . 671)
 > (external-border-size 8 . 8) (title-bar-size 651 . 23)
 > (menu-bar-external . t) (menu-bar-size 673 . 20) (tool-bar-external)
 > (tool-bar-position . top) (tool-bar-size 689 . 36)
 > (internal-border-width . 0))

All these values are consistent now and indicate that the frame has
returned to its normal state after step 3.

 > These values (after final step) are the same I get at the very
 > beginning (just after "emacs -Q").

Everything seems clear - the bug is all mine.  Windows just told us that
the frame was maximized but the simple hack in w32.term.c

		case SIZE_MAXIMIZED:
		  ...
		  /* 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.  */
		  if (EQ (fullscreen, Qfullwidth) || EQ (fullscreen, Qfullheight)
		      || NILP (fullscreen))
		      {
			int x, y;

			x_real_positions (f, &x, &y);
			if (x < 0 && y < 0)
			  store_frame_param (f, Qfullscreen, Qmaximized);
		      }

fails becaue either x (in your case) or y (in the taskbar at top case)
are greater zero.  (I boldly assume that NILP (fullscreen) held, maybe
Noam can verify - I never move my taskbar.)  I could replace

			if (x < 0 && y < 0)
			
with

			if (x < 0 || y < 0)

to handle the two cases but that check appears downright silly and will
fail anyway for border-less, maximized frames.  I must devise something
better.

Thanks for all the information you sent, martin

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

[Noam Postavsky]

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

On Fri, Jan 27, 2017 at 8:47 AM, martin rudalics <rudalics@gmx.at> wrote:
> Everything seems clear - the bug is all mine.  Windows just told us that
> the frame was maximized but the simple hack in w32.term.c
>
>                 case SIZE_MAXIMIZED:
>                   ...
>                   /* 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.  */
>                   if (EQ (fullscreen, Qfullwidth) || EQ (fullscreen,
> Qfullheight)
>                       || NILP (fullscreen))
>                       {
>                         int x, y;
>
>                         x_real_positions (f, &x, &y);
>                         if (x < 0 && y < 0)
>                           store_frame_param (f, Qfullscreen, Qmaximized);
>                       }
>
> fails becaue either x (in your case) or y (in the taskbar at top case)
> are greater zero.  (I boldly assume that NILP (fullscreen) held, maybe
> Noam can verify - I never move my taskbar.)

Your assumption is correct. I added some message calls to master (as
in the attached diff). With the taskbar on the left I got:

SIZE_MAXIMIZED, fullscreen = nil
SIZE_MAXIMIZED, x = 54, y = -8

on the maximize, and

SIZE_MAXIMIZED, fullscreen = fullboth

on hitting f11 the first time. Nothing the second time (when Emacs
incorrectly switches to non-maximized state).

With the taskbar on top it's the same except x = -8, y = 22 (when
taskbar is on the right or botton both x and y are -8 and the the
second f11 produces the same message as maximizing).

[-- Attachment #2: w32term.c.msg.diff --]
[-- Type: text/plain, Size: 955 bytes --]

diff --git i/src/w32term.c w/src/w32term.c
index d6b78fd..9627019 100644
--- i/src/w32term.c
+++ w/src/w32term.c
@@ -5110,12 +5110,18 @@ 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.  */
+                    {
+                      AUTO_STRING (format, "SIZE_MAXIMIZED, fullscreen = %s");
+                      CALLN (Fmessage, format, SYMBOL_NAME (fullscreen));
+                    }
 		  if (EQ (fullscreen, Qfullwidth) || EQ (fullscreen, Qfullheight)
 		      || NILP (fullscreen))
 		      {
 			int x, y;
 
 			x_real_positions (f, &x, &y);
+                        AUTO_STRING (format, "SIZE_MAXIMIZED, x = %d, y = %d");
+                        CALLN (Fmessage, format, make_number (x), make_number (y));
 			if (x < 0 && y < 0)
 			  store_frame_param (f, Qfullscreen, Qmaximized);
 		      }

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

[martin rudalics]

 > Your assumption is correct. I added some message calls to master (as
 > in the attached diff). With the taskbar on the left I got:
 >
 > SIZE_MAXIMIZED, fullscreen = nil
 > SIZE_MAXIMIZED, x = 54, y = -8
 >
 > on the maximize, and
 >
 > SIZE_MAXIMIZED, fullscreen = fullboth
 >
 > on hitting f11 the first time. Nothing the second time (when Emacs
 > incorrectly switches to non-maximized state).
 >
 > With the taskbar on top it's the same except x = -8, y = 22 (when
 > taskbar is on the right or botton both x and y are -8 and the the
 > second f11 produces the same message as maximizing).

Thank you very much for checking.  I suppose that replacing

		  if (EQ (fullscreen, Qfullwidth) || EQ (fullscreen, Qfullheight)
		      || NILP (fullscreen))
		      {
			int x, y;

			x_real_positions (f, &x, &y);
			if (x < 0 && y < 0)
			  store_frame_param (f, Qfullscreen, Qmaximized);
		      }

with

			  store_frame_param (f, Qfullscreen, Qmaximized);

should work because I doubt that "Windows can send us a SIZE_MAXIMIZED
message even when fullscreen is fullboth" can happen but who knows ...

martin

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

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

>> With the taskbar on top it's the same except x = -8, y = 22 (when
>> taskbar is on the right or botton both x and y are -8 and the the
>> second f11 produces the same message as maximizing).
>
> Thank you very much for checking.  I suppose that replacing
>
> 		  if (EQ (fullscreen, Qfullwidth) || EQ (fullscreen, Qfullheight)
> 		      || NILP (fullscreen))
> 		      {
> 			int x, y;
>
> 			x_real_positions (f, &x, &y);
> 			if (x < 0 && y < 0)
> 			  store_frame_param (f, Qfullscreen, Qmaximized);
> 		      }
>
> with
>
> 			  store_frame_param (f, Qfullscreen, Qmaximized);
>
> should work because I doubt that "Windows can send us a SIZE_MAXIMIZED
> message even when fullscreen is fullboth" can happen but who knows ...

Reading this thread, it seems like the problem was analysed thoroughly,
but this was the final message in the thread.  Did anybody try this
solution to see whether it fixes the problem, or has the problem been
fixed in a different way over the years?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Dani Moncayo]

On Fri, Sep 4, 2020 at 2:33 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> [...]
> Did anybody try this
> solution to see whether it fixes the problem, or has the problem been
> fixed in a different way over the years?

I've just seen that the bug is still present in the version I'm using:

  GNU Emacs 27.1 (build 1, x86_64-pc-cygwin)
   of 2020-08-11

(Sorry, I don't have currently a suitable build environment for Emacs,
so I can't try the proposed fix)

-- 
Dani Moncayo

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

[Eli Zaretskii]

> From: Dani Moncayo <dmoncayo@gmail.com>
> Date: Fri, 4 Sep 2020 19:50:59 +0200
> Cc: 25542@debbugs.gnu.org, Noam Postavsky <npostavs@users.sourceforge.net>
> 
> On Fri, Sep 4, 2020 at 2:33 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> > [...]
> > Did anybody try this
> > solution to see whether it fixes the problem, or has the problem been
> > fixed in a different way over the years?
> 
> I've just seen that the bug is still present in the version I'm using:
> 
>   GNU Emacs 27.1 (build 1, x86_64-pc-cygwin)
>    of 2020-08-11

This problem is specific to the Cywgin's w32 build, so someone who
uses it should try the patch.

I cannot say that I'm happy with the patch, though: it affects the
native w32 build as well, where the problem doesn't happen in the
first place.  If it helps, maybe we should make the change conditional
on CYGWIN or something.

Ken, can you try the patch, please?  And WDYT about the solution?

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

[Dani Moncayo]

On Sat, Sep 5, 2020 at 8:47 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> [...]
> This problem is specific to the Cywgin's w32 build
> [...]

I've just downloaded a native w32 build [1] and I've run it on my
system (MS Windows 10 Enterprise). I see the same problem with this
native build.

[1] http://ftp.rediris.es/mirror/GNU/emacs/windows/emacs-27/emacs-27.1-x86_64.zip

  This is GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)
   of 2020-08-21

-- 
Dani Moncayo

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

[Eli Zaretskii]

> From: Dani Moncayo <dmoncayo@gmail.com>
> Date: Sat, 5 Sep 2020 13:59:46 +0200
> Cc: Ken Brown <kbrown@cornell.edu>, Lars Magne Ingebrigtsen <larsi@gnus.org>, 25542@debbugs.gnu.org, 
> 	Noam Postavsky <npostavs@users.sourceforge.net>, martin rudalics <rudalics@gmx.at>
> 
> > This problem is specific to the Cywgin's w32 build
> > [...]
> 
> I've just downloaded a native w32 build [1] and I've run it on my
> system (MS Windows 10 Enterprise). I see the same problem with this
> native build.

Then we have a reproducibility problem, because I don't see this with
the native build, and neither did Martin at the time (see his initial
response to the original bug report).

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

[Dani Moncayo]

On Sat, Sep 5, 2020 at 2:17 PM Eli Zaretskii <eliz@gnu.org> wrote:
> [...]
> Then we have a reproducibility problem, because I don't see this with
> the native build, and neither did Martin at the time (see his initial
> response to the original bug report).

Did you try with the taskbar attached to the left side of the screen?

That is required to trigger the problem, as I said in this message:
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25542#29


-- 
Dani Moncayo

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

[Eli Zaretskii]

> From: Dani Moncayo <dmoncayo@gmail.com>
> Date: Sat, 5 Sep 2020 14:19:10 +0200
> Cc: Ken Brown <kbrown@cornell.edu>, Lars Magne Ingebrigtsen <larsi@gnus.org>, 25542@debbugs.gnu.org, 
> 	Noam Postavsky <npostavs@users.sourceforge.net>, martin rudalics <rudalics@gmx.at>
> 
> On Sat, Sep 5, 2020 at 2:17 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > [...]
> > Then we have a reproducibility problem, because I don't see this with
> > the native build, and neither did Martin at the time (see his initial
> > response to the original bug report).
> 
> Did you try with the taskbar attached to the left side of the screen?

No.  And it isn't clear to me whether Martin did.

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

[Dani Moncayo]

On Sat, Sep 5, 2020 at 2:30 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Dani Moncayo <dmoncayo@gmail.com>
> > Date: Sat, 5 Sep 2020 14:19:10 +0200
> > Cc: Ken Brown <kbrown@cornell.edu>, Lars Magne Ingebrigtsen <larsi@gnus.org>, 25542@debbugs.gnu.org,
> >       Noam Postavsky <npostavs@users.sourceforge.net>, martin rudalics <rudalics@gmx.at>
> >
> > On Sat, Sep 5, 2020 at 2:17 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > > [...]
> > > Then we have a reproducibility problem, because I don't see this with
> > > the native build, and neither did Martin at the time (see his initial
> > > response to the original bug report).
> >
> > Did you try with the taskbar attached to the left side of the screen?
>
> No.  And it isn't clear to me whether Martin did.

OK.  So, are you able to reproduce the problem now?

BTW, another detail I've just noticed to reproduce the problem: in the
"taskbar settings" the flag "Automatically hide the taskbar" must be
turned off.

-- 
Dani Moncayo

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

[Eli Zaretskii]

> From: Dani Moncayo <dmoncayo@gmail.com>
> Date: Sat, 5 Sep 2020 14:32:04 +0200
> Cc: Ken Brown <kbrown@cornell.edu>, Lars Magne Ingebrigtsen <larsi@gnus.org>, 25542@debbugs.gnu.org, 
> 	Noam Postavsky <npostavs@users.sourceforge.net>, martin rudalics <rudalics@gmx.at>
> 
> > > Did you try with the taskbar attached to the left side of the screen?
> >
> > No.  And it isn't clear to me whether Martin did.
> 
> OK.  So, are you able to reproduce the problem now?

I didn't try.  Not enough time, sorry.

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

[Ken Brown]

On 9/5/2020 8:32 AM, Dani Moncayo wrote:
> On Sat, Sep 5, 2020 at 2:30 PM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>> From: Dani Moncayo <dmoncayo@gmail.com>
>>> Date: Sat, 5 Sep 2020 14:19:10 +0200
>>> Cc: Ken Brown <kbrown@cornell.edu>, Lars Magne Ingebrigtsen <larsi@gnus.org>, 25542@debbugs.gnu.org,
>>>        Noam Postavsky <npostavs@users.sourceforge.net>, martin rudalics <rudalics@gmx.at>
>>>
>>> On Sat, Sep 5, 2020 at 2:17 PM Eli Zaretskii <eliz@gnu.org> wrote:
>>>> [...]
>>>> Then we have a reproducibility problem, because I don't see this with
>>>> the native build, and neither did Martin at the time (see his initial
>>>> response to the original bug report).
>>>
>>> Did you try with the taskbar attached to the left side of the screen?
>>
>> No.  And it isn't clear to me whether Martin did.
> 
> OK.  So, are you able to reproduce the problem now?
> 
> BTW, another detail I've just noticed to reproduce the problem: in the
> "taskbar settings" the flag "Automatically hide the taskbar" must be
> turned off.

I can reproduce the problem on the Cygwin w32 build, but Martin's suggestion 
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25542#83) doesn't fix it.  He 
suggested the following, if I understand correctly:

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.

Ken

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

[Eli Zaretskii]

> 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.

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

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

[Eli Zaretskii]

> Cc: dmoncayo@gmail.com, larsi@gnus.org, 25542@debbugs.gnu.org,
>  npostavs@users.sourceforge.net, rudalics@gmx.at
> From: Ken Brown <kbrown@cornell.edu>
> Date: Sat, 5 Sep 2020 12:10:59 -0400
> 
> > 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.

You are right, sorry for my confusion.

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

[martin rudalics]

 > I've just downloaded a native w32 build [1] and I've run it on my
 > system (MS Windows 10 Enterprise). I see the same problem with this
 > native build.

Can you please run under gdb with a breakpoint in w32fullscreen_hook of
w32term.c suitably in here

       else if (f->want_fullscreen == FULLSCREEN_MAXIMIZED)
	{
	  if (prev_fsmode == FULLSCREEN_BOTH || prev_fsmode == FULLSCREEN_WIDTH
	      || prev_fsmode == FULLSCREEN_HEIGHT)
	    /* Make window normal since otherwise the subsequent
	       maximization might fail in some cases.  */
	    ShowWindow (hwnd, SW_SHOWNORMAL);
	  ShowWindow (hwnd, SW_MAXIMIZE);
	}

and tell us how the frame appears immediately after the ShowWindow
calls.  Here the first call makes the frame appear with its "normal"
size, the second one makes it appear maximized.

Thank you, martin

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

[Dani Moncayo]

On Wed, Sep 9, 2020 at 10:44 AM martin rudalics <rudalics@gmx.at> wrote:
> [...]
> Can you please run under gdb [...]

As I said a couple of days ago, I don't have currently a build/debug
environment for Emacs, sorry.

Anyway, I think the problem is very easily reproducible, isn't it?

-- 
Dani Moncayo

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

[Ken Brown]

On 9/9/2020 4:44 AM, martin rudalics wrote:
>  > I've just downloaded a native w32 build [1] and I've run it on my
>  > system (MS Windows 10 Enterprise). I see the same problem with this
>  > native build.
> 
> Can you please run under gdb with a breakpoint in w32fullscreen_hook of
> w32term.c suitably in here
> 
>        else if (f->want_fullscreen == FULLSCREEN_MAXIMIZED)
>      {
>        if (prev_fsmode == FULLSCREEN_BOTH || prev_fsmode == FULLSCREEN_WIDTH
>            || prev_fsmode == FULLSCREEN_HEIGHT)
>          /* Make window normal since otherwise the subsequent
>             maximization might fail in some cases.  */
>          ShowWindow (hwnd, SW_SHOWNORMAL);
>        ShowWindow (hwnd, SW_MAXIMIZE);
>      }
> 
> and tell us how the frame appears immediately after the ShowWindow
> calls.  Here the first call makes the frame appear with its "normal"
> size, the second one makes it appear maximized.

I just tried this on a Cygwin-w32 build from the master branch.  I put the 
taskbar on the left, started emacs, maximized it, attached gdb, put breakpoints 
at each of the ShowWindow lines, and ran through Dani's recipe for producing the 
bug.  The breakpoints were never hit.

Ken

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

[Ken Brown]

On 9/9/2020 2:19 PM, Ken Brown wrote:
> On 9/9/2020 4:44 AM, martin rudalics wrote:
>>  > I've just downloaded a native w32 build [1] and I've run it on my
>>  > system (MS Windows 10 Enterprise). I see the same problem with this
>>  > native build.
>>
>> Can you please run under gdb with a breakpoint in w32fullscreen_hook of
>> w32term.c suitably in here
>>
>>        else if (f->want_fullscreen == FULLSCREEN_MAXIMIZED)
>>      {
>>        if (prev_fsmode == FULLSCREEN_BOTH || prev_fsmode == FULLSCREEN_WIDTH
>>            || prev_fsmode == FULLSCREEN_HEIGHT)
>>          /* Make window normal since otherwise the subsequent
>>             maximization might fail in some cases.  */
>>          ShowWindow (hwnd, SW_SHOWNORMAL);
>>        ShowWindow (hwnd, SW_MAXIMIZE);
>>      }
>>
>> and tell us how the frame appears immediately after the ShowWindow
>> calls.  Here the first call makes the frame appear with its "normal"
>> size, the second one makes it appear maximized.
> 
> I just tried this on a Cygwin-w32 build from the master branch.  I put the 
> taskbar on the left, started emacs, maximized it, attached gdb, put breakpoints 
> at each of the ShowWindow lines, and ran through Dani's recipe for producing the 
> bug.  The breakpoints were never hit.

I just tried again, but this time with a breakpoint at w32fullscreen_hook so 
that I could follow the flow.  Here are the relevant excerpts from the gdb session:

$ gdb ./emacs
GNU gdb (GDB) (Cygwin 9.2-1) 9.2

[...]

(gdb) b w32fullscreen_hook
Breakpoint 2 at 0x10069507a: file ../../master/src/w32term.c, line 6441.
(gdb) r -Q
Starting program: /home/kbrown/src/emacs/x86_64-w32/src/emacs -Q

[...]

[Press F11]

Thread 1 "emacs" hit Breakpoint 2, w32fullscreen_hook (f=0x8001f7c88)
     at ../../master/src/w32term.c:6441
6441      if (FRAME_VISIBLE_P (f))
(gdb) n
6443          HWND hwnd = FRAME_W32_WINDOW(f);
(gdb)
6444          DWORD dwStyle = GetWindowLong (hwnd, GWL_STYLE);
(gdb)
6446          enum fullscreen_type prev_fsmode = FRAME_PREV_FSMODE (f);
(gdb)
6448          block_input();
(gdb)
6449          f->want_fullscreen &= ~FULLSCREEN_WAIT;
(gdb)
6451          if (FRAME_PREV_FSMODE (f) == FULLSCREEN_NONE)
(gdb)
6452            GetWindowPlacement (hwnd, &FRAME_NORMAL_PLACEMENT (f));
(gdb)
6454          if (FRAME_PREV_FSMODE (f) == FULLSCREEN_BOTH)
(gdb)
6460          else if (FRAME_PREV_FSMODE (f) == FULLSCREEN_HEIGHT
(gdb)
6461                   || FRAME_PREV_FSMODE (f) == FULLSCREEN_WIDTH)
(gdb)
6464          FRAME_PREV_FSMODE (f) = f->want_fullscreen;
(gdb) p f->want_fullscreen
$1 = FULLSCREEN_BOTH
(gdb) n
6466          if (f->want_fullscreen == FULLSCREEN_NONE)
(gdb)
6468          else if (f->want_fullscreen == FULLSCREEN_MAXIMIZED)
(gdb)
6477          else if (f->want_fullscreen == FULLSCREEN_BOTH)
(gdb)
6479              int menu_bar_height = GetSystemMetrics (SM_CYMENU);
(gdb)
6482                                   FRAME_NORMAL_PLACEMENT 
(f).rcNormalPosition, &rect);
(gdb)
6481              w32_fullscreen_rect (hwnd, f->want_fullscreen,
(gdb)
6483              if (!FRAME_UNDECORATED (f))
(gdb)
6484                SetWindowLong (hwnd, GWL_STYLE, dwStyle & ~WS_OVERLAPPEDWINDOW);
(gdb)
6486                            rect.right - rect.left, rect.bottom - rect.top,
(gdb)
6485              SetWindowPos (hwnd, HWND_TOP, rect.left, rect.top,
(gdb)
6486                            rect.right - rect.left, rect.bottom - rect.top,
(gdb)
6485              SetWindowPos (hwnd, HWND_TOP, rect.left, rect.top,
(gdb)
6490                 FRAME_PIXEL_TO_TEXT_HEIGHT (f, (rect.bottom - rect.top
(gdb)
6488              change_frame_size
(gdb)
6489                (f, FRAME_PIXEL_TO_TEXT_WIDTH (f, rect.right - rect.left),
(gdb)
6488              change_frame_size
(gdb)
6526          f->want_fullscreen = FULLSCREEN_NONE;
(gdb)
6527          unblock_input ();
(gdb)
6529          if (f->want_fullscreen == FULLSCREEN_BOTH
(gdb)
6530              || f->want_fullscreen == FULLSCREEN_WIDTH
(gdb)
6531              || f->want_fullscreen == FULLSCREEN_HEIGHT)
(gdb)
6537    }

[...]

(gdb) c
Continuing.

[Press F11 again]

Thread 1 "emacs" hit Breakpoint 2, w32fullscreen_hook (f=0x8001f7c88)
     at ../../master/src/w32term.c:6441
6441      if (FRAME_VISIBLE_P (f))
(gdb) n
6443          HWND hwnd = FRAME_W32_WINDOW(f);
(gdb)
6444          DWORD dwStyle = GetWindowLong (hwnd, GWL_STYLE);
(gdb)
6446          enum fullscreen_type prev_fsmode = FRAME_PREV_FSMODE (f);
(gdb)
6448          block_input();
(gdb)
6449          f->want_fullscreen &= ~FULLSCREEN_WAIT;
(gdb)
6451          if (FRAME_PREV_FSMODE (f) == FULLSCREEN_NONE)
(gdb) p f->want_fullscreen
$2 = FULLSCREEN_NONE
(gdb) n
6454          if (FRAME_PREV_FSMODE (f) == FULLSCREEN_BOTH)
(gdb)
6456              if (!FRAME_UNDECORATED (f))
(gdb)
6457                SetWindowLong (hwnd, GWL_STYLE, dwStyle | WS_OVERLAPPEDWINDOW);
(gdb)
6458              SetWindowPlacement (hwnd, &FRAME_NORMAL_PLACEMENT (f));
(gdb)
6464          FRAME_PREV_FSMODE (f) = f->want_fullscreen;
(gdb)
6466          if (f->want_fullscreen == FULLSCREEN_NONE)
(gdb)
6467            ShowWindow (hwnd, SW_SHOWNORMAL);

[Now the frame reverts to an unmaximized state, exhibiting the bug.]

Ken

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

[martin rudalics]

 >> I just tried this on a Cygwin-w32 build from the master branch.  I put the taskbar on the left, started emacs, maximized it, attached gdb, put breakpoints at each of the ShowWindow lines, and ran through Dani's recipe for producing the bug.  The breakpoints were never hit.
 >
 > I just tried again, but this time with a breakpoint at w32fullscreen_hook so that I could follow the flow.  Here are the relevant excerpts from the gdb session:

Thank you very much for checking.

 > Breakpoint 2 at 0x10069507a: file ../../master/src/w32term.c, line 6441.
 > (gdb) r -Q
 > Starting program: /home/kbrown/src/emacs/x86_64-w32/src/emacs -Q
 >
 > [...]
 >
 > [Press F11]
 >
 > Thread 1 "emacs" hit Breakpoint 2, w32fullscreen_hook (f=0x8001f7c88)
 >      at ../../master/src/w32term.c:6441
[...]
 > 6464          FRAME_PREV_FSMODE (f) = f->want_fullscreen;
 > (gdb) p f->want_fullscreen
 > $1 = FULLSCREEN_BOTH

While this is the expected value ...

 > [...]
 >
 > (gdb) c
 > Continuing.
 >
 > [Press F11 again]
 >
 > Thread 1 "emacs" hit Breakpoint 2, w32fullscreen_hook (f=0x8001f7c88)
 >      at ../../master/src/w32term.c:6441
[...]
 > 6451          if (FRAME_PREV_FSMODE (f) == FULLSCREEN_NONE)
 > (gdb) p f->want_fullscreen
 > $2 = FULLSCREEN_NONE

... the value I would have expected here is FULLSCREEN_MAXIMIZED.
Something must have got broken before.  Can you please

(1) Verify that the

       f->want_fullscreen &= ~FULLSCREEN_WAIT;

     does not interfere in any respect.  That is, does f->want_fullscreen
     have the same value FULLSCREEN_NONE before anding it with
     FULLSCREEN_WAIT?

(2) Does 'toggle-frame-fullscreen' the second time when you type F11
     correctly call

    (set-frame-parameter frame 'fullscreen fullscreen-restore)

    with 'fullscreen-restore' equal to 'maximized' at all?

(3) Verify that calling w32fullscreen_hook with the taskbar on the
     bottom does hit the breakpoints and subsequently maximize the frame
     as expected.

Thanks again, martin

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

[Ken Brown]

On 9/10/2020 3:16 AM, martin rudalics wrote:
>  >> I just tried this on a Cygwin-w32 build from the master branch.  I put the 
> taskbar on the left, started emacs, maximized it, attached gdb, put breakpoints 
> at each of the ShowWindow lines, and ran through Dani's recipe for producing the 
> bug.  The breakpoints were never hit.
>  >
>  > I just tried again, but this time with a breakpoint at w32fullscreen_hook so 
> that I could follow the flow.  Here are the relevant excerpts from the gdb session:
> 
> Thank you very much for checking.
> 
>  > Breakpoint 2 at 0x10069507a: file ../../master/src/w32term.c, line 6441.
>  > (gdb) r -Q
>  > Starting program: /home/kbrown/src/emacs/x86_64-w32/src/emacs -Q
>  >
>  > [...]
>  >
>  > [Press F11]
>  >
>  > Thread 1 "emacs" hit Breakpoint 2, w32fullscreen_hook (f=0x8001f7c88)
>  >      at ../../master/src/w32term.c:6441
> [...]
>  > 6464          FRAME_PREV_FSMODE (f) = f->want_fullscreen;
>  > (gdb) p f->want_fullscreen
>  > $1 = FULLSCREEN_BOTH
> 
> While this is the expected value ...
> 
>  > [...]
>  >
>  > (gdb) c
>  > Continuing.
>  >
>  > [Press F11 again]
>  >
>  > Thread 1 "emacs" hit Breakpoint 2, w32fullscreen_hook (f=0x8001f7c88)
>  >      at ../../master/src/w32term.c:6441
> [...]
>  > 6451          if (FRAME_PREV_FSMODE (f) == FULLSCREEN_NONE)
>  > (gdb) p f->want_fullscreen
>  > $2 = FULLSCREEN_NONE
> 
> ... the value I would have expected here is FULLSCREEN_MAXIMIZED.
> Something must have got broken before.  Can you please
> 
> (1) Verify that the
> 
>        f->want_fullscreen &= ~FULLSCREEN_WAIT;
> 
>      does not interfere in any respect.  That is, does f->want_fullscreen
>      have the same value FULLSCREEN_NONE before anding it with
>      FULLSCREEN_WAIT?

Yes.

> (2) Does 'toggle-frame-fullscreen' the second time when you type F11
>      correctly call
> 
>     (set-frame-parameter frame 'fullscreen fullscreen-restore)
> 
>     with 'fullscreen-restore' equal to 'maximized' at all?

No.  The value of 'fullscreen-restore' is nil.  But if I repeat the experiment 
with the taskbar on the bottom, the value of fullscreen-restore is 'maximized'.

> (3) Verify that calling w32fullscreen_hook with the taskbar on the
>      bottom does hit the breakpoints and subsequently maximize the frame
>      as expected.

With the taskbar on the bottom, f->want_fullscreen == FULLSCREEN_MAXIMIZED when 
I hit line 6449 after the second F11, and everything goes as expected after that.

Ken

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

[martin rudalics]

 >> (2) Does 'toggle-frame-fullscreen' the second time when you type F11
 >>      correctly call
 >>
 >>     (set-frame-parameter frame 'fullscreen fullscreen-restore)
 >>
 >>     with 'fullscreen-restore' equal to 'maximized' at all?
 >
 > No.  The value of 'fullscreen-restore' is nil.  But if I repeat the experiment with the taskbar on the bottom, the value of fullscreen-restore is 'maximized'.

Thanks for telling me what I forgot to ask.  IIUC this means that after
maximizing the frame with the mouse, the value of

(frame-parameter nil 'fullscreen)

is nil.  Correct?  And what is its value if, instead, you maximize the
frame via 'toggle-frame-maximized'?

In either case the bug should be a consequence of the earlier mentioned

			if (x < 0 && y < 0)
			  store_frame_param (f, Qfullscreen, Qmaximized);

so we do not remember in the fullscreen parameter that the frame has
been maximized.  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)?

martin

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

[Ken Brown]

On 9/10/2020 2:16 PM, martin rudalics wrote:
>  >> (2) Does 'toggle-frame-fullscreen' the second time when you type F11
>  >>      correctly call
>  >>
>  >>     (set-frame-parameter frame 'fullscreen fullscreen-restore)
>  >>
>  >>     with 'fullscreen-restore' equal to 'maximized' at all?
>  >
>  > No.  The value of 'fullscreen-restore' is nil.  But if I repeat the 
> experiment with the taskbar on the bottom, the value of fullscreen-restore is 
> 'maximized'.
> 
> Thanks for telling me what I forgot to ask.  IIUC this means that 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.

> In either case the bug should be a consequence of the earlier mentioned
> 
>              if (x < 0 && y < 0)
>                store_frame_param (f, Qfullscreen, Qmaximized);
> 
> so we do not remember in the fullscreen parameter that the frame has
> been maximized.  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.  I haven't tried to test anything involving borderless 
frames.

Ken

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

[martin rudalics]

 >> ... 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?

 > 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

(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

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

[Ken Brown]

[-- 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

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

[Achim Gratz]

Ken Brown writes:
>> 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.

I think he's referring to the Win+Up shortcut, which maximizes the frame
on the current screen.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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

[Ken Brown]

On 9/11/2020 4:33 PM, Achim Gratz wrote:
> Ken Brown writes:
>>> 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.
> 
> I think he's referring to the Win+Up shortcut, which maximizes the frame
> on the current screen.

Thanks, I didn't know about that.  Martin, is that what you meant?  Do you want 
me to play with that and answer your questions before installing the other patch?

Ken

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

[martin rudalics]

 > Thanks, I didn't know about that.  Martin, is that what you meant?  Do you want me to play with that and answer your questions before installing the other patch?

No.  Please go ahead and install the patch.  Maybe, as soon as I can
build master again, I'll play around with this myself.

martin

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

[Ken Brown]

On 9/12/2020 2:54 AM, martin rudalics wrote:
>  > Thanks, I didn't know about that.  Martin, is that what you meant?  Do you 
> want me to play with that and answer your questions before installing the other 
> patch?
> 
> No.  Please go ahead and install the patch.  Maybe, as soon as I can
> build master again, I'll play around with this myself.

Done.  Closing.

Ken

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

[martin rudalics]

 > I think he's referring to the Win+Up shortcut, which maximizes the frame
 > on the current screen.

Right.  Wasn't that part of something they called Aero on Windows 7?

martin

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

[Eli Zaretskii]

> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>, 25542@debbugs.gnu.org,
>  Noam Postavsky <npostavs@users.sourceforge.net>
> From: Ken Brown <kbrown@cornell.edu>
> Date: Fri, 11 Sep 2020 16:16:09 -0400
> 
> 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?

Yes, I definitely agree: the use case is rare and the fix is not
self-evident.

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

[martin rudalics]

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

Looks perfect to me.

Many thanks, martin

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

[Eli Zaretskii]

> Date: Thu, 26 Jan 2017 10:51:48 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
>  > Recipe from "emacs -Q"
>  >
>  > 1. Maximize the frame using the mouse -- for example, on MS-Windows,
>  > either click on the "maximize" button or double click on the title
>  > bar.
>  >
>  > 2. Switch to fullscreen by pressing F11.
>  >
>  > 3. Press F11 again.
>  >
>  >
>  > Expected behavior: The frame goes to its previous state (i.e. maximized).
> 
> This is the behavior I get with my MinGW builds on Windows XP.

As do I.  I also tested on Windows 7, and I see the same expected
behavior there.