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