bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen

bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen

[Jonathan Kyle Mitchell]

1. save a frameset with an unmaximized frame
start from emacs -Q
create a second window with `C-x 2'
use the mouse to move the frame to the right side of the desktop
save the split window frame with `C-x r f a'

2. save a frameset with a maximized/fullscreen frame
delete one of the windows with `C-x 1'
press `f11' to make the frame fullscreen
save the fullscreen frame with `C-x r f b'

3. restore the unmaximized frameset with `C-x r j a'
After jumping between framesets from register b to register a, the
non-fullscreen frame appears on the opposite (left) side of the desktop
than it was originally. Typing `C-x r j a' a second time moves the frame
to its original location.

I've reproduced this using Emacs 26.1 in both Windows 10 and Fedora 28
KDE desktop environments.

In GNU Emacs 26.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.22.30)
 of 2018-06-04 built on buildvm-10.phx2.fedoraproject.org
Windowing system distributor 'Fedora Project', version 11.0.11906000
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
C-x C-g is undefined
Quit
funcall-interactively: End of buffer

Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets --with-modules
 build_alias=x86_64-redhat-linux-gnu host_alias=x86_64-redhat-linux-gnu
 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -Wall -Werror=format-security
 -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
 -fstack-protector-strong -grecord-gcc-switches
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY ACL
LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES THREADS XWIDGETS LCMS2

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

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
mml-sec password-cache epa derived epg epg-config gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils cl-extra help-mode easymenu cl-seq
frameset cl-loaddefs cl-lib elec-pair time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting xwidget-internal move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 98781 10240)
 (symbols 48 20607 1)
 (miscs 40 49 104)
 (strings 32 28810 1074)
 (string-bytes 1 760814)
 (vectors 16 15071)
 (vector-slots 8 500054 6618)
 (floats 8 56 318)
 (intervals 56 275 0)
 (buffers 992 11))

bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen

[martin rudalics]

 > 1. save a frameset with an unmaximized frame
 > start from emacs -Q
 > create a second window with `C-x 2'
 > use the mouse to move the frame to the right side of the desktop
 > save the split window frame with `C-x r f a'
 >
 > 2. save a frameset with a maximized/fullscreen frame
 > delete one of the windows with `C-x 1'
 > press `f11' to make the frame fullscreen
 > save the fullscreen frame with `C-x r f b'
 >
 > 3. restore the unmaximized frameset with `C-x r j a'
 > After jumping between framesets from register b to register a, the
 > non-fullscreen frame appears on the opposite (left) side of the desktop
 > than it was originally. Typing `C-x r j a' a second time moves the frame
 > to its original location.
 >
 > I've reproduced this using Emacs 26.1 in both Windows 10 and Fedora 28
 > KDE desktop environments.
 >
 > In GNU Emacs 26.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.22.30)
 >   of 2018-06-04 built on buildvm-10.phx2.fedoraproject.org

Thanks for the report.  Here I can't reproduce the behavior you
observe on Windows XP even if I modify your recipe in various ways.
Maybe someone else can give it a try.

Do you really have to split the window in step 1 and delete a window
in step 2 to produce the bug?  These actions appear unrelated to the
behavior you observe since window managers pretty much ignore Emacs
windows.

Also what happens if, in step 2, you maximize the window instead of
making it fullscreen?  frameset.el has

     (modify-frame-parameters frame
			     (if (eq (frame-parameter frame 'fullscreen) fullscreen)
				 ;; Workaround for bug#14949
				 (assq-delete-all 'fullscreen filtered-cfg)
			       filtered-cfg))

which might affect the behavior on your system.  Can you take out this
form, reevaluate 'frameset--restore-frame' and see whether anything
changes?

And maybe you could also try with

     (when (and force-onscreen
	       ;; FIXME: iconified frames should be checked too,
	       ;; but it is impossible without deiconifying them.
	       (not (eq (frame-parameter frame 'visibility) 'icon)))
       (frameset-move-onscreen frame force-onscreen))

removed from 'frameset--restore-frame'.

martin

bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> In GNU Emacs 26.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.22.30)
>>   of 2018-06-04 built on buildvm-10.phx2.fedoraproject.org
>
> Thanks for the report.  Here I can't reproduce the behavior you
> observe on Windows XP even if I modify your recipe in various ways.
> Maybe someone else can give it a try.
>

I see this on my Ubuntu 16.04 box, also running KDE, but only if I go
through the restore cycle twice. Also, if I restore frameset a again,
the frame ends up in the right place, ie:

restore a -> OK
restore b -> OK
restore a -> NOK
restore a -> OK

> Do you really have to split the window in step 1 and delete a window
> in step 2 to produce the bug?  These actions appear unrelated to the
> behavior you observe since window managers pretty much ignore Emacs
> windows.

I donʼt need to split the window.

> Also what happens if, in step 2, you maximize the window instead of
> making it fullscreen?  frameset.el has
>
>     (modify-frame-parameters frame
> 			     (if (eq (frame-parameter frame 'fullscreen) fullscreen)
> 				 ;; Workaround for bug#14949
> 				 (assq-delete-all 'fullscreen filtered-cfg)
> 			       filtered-cfg))
>
> which might affect the behavior on your system.  Can you take out this
> form, reevaluate 'frameset--restore-frame' and see whether anything
> changes?
>
> And maybe you could also try with
>
>     (when (and force-onscreen
> 	       ;; FIXME: iconified frames should be checked too,
> 	       ;; but it is impossible without deiconifying them.
> 	       (not (eq (frame-parameter frame 'visibility) 'icon)))
>       (frameset-move-onscreen frame force-onscreen))
>
> removed from 'frameset--restore-frame'.

Neither of those make any difference for me, nor does using
toggle-frame-maximized.

Regards

Robert

bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen

[martin rudalics]

 > I see this on my Ubuntu 16.04 box, also running KDE, but only if I go
 > through the restore cycle twice. Also, if I restore frameset a again,
 > the frame ends up in the right place, ie:
 >
 > restore a -> OK
 > restore b -> OK
 > restore a -> NOK
 > restore a -> OK

Confirmed.  The transition from b to a via C-x r j a always moves the
frame to the top/left corner of the screen here.

IIUC C-x r f runs the command 'frameset-to-register' which stores a
"framset" in a register.  C-x r j runs the command 'jump-to-register'
which does _not_ restore a frame's state via 'frameset--restore-frame'
but goes to 'set-frame-configuration' instead.  Apparently, framesets
and frame configurations differ in a couple of minor aspects and the
fullscreen state is one of them.

We probably should replace

     (set-frame-configuration (car val) (not delete))

by something like

     (frameset-restore (car val))

but my knowledge of constructs like 'cl-defmethod' and 'cl-defun' is
too limited to play around with such a change.  Maybe someone wants to
give it at try, it should be a rather low-hanging fruit.

 > Neither of those make any difference for me, nor does using
 > toggle-frame-maximized.

Obviously so because 'frameset--restore-frame' does not get called in
the first place.

Thanks for investigating, martin

bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> I see this on my Ubuntu 16.04 box, also running KDE, but only if I go
>> through the restore cycle twice. Also, if I restore frameset a again,
>> the frame ends up in the right place, ie:
>>
>> restore a -> OK
>> restore b -> OK
>> restore a -> NOK
>> restore a -> OK
>
> Confirmed.  The transition from b to a via C-x r j a always moves the
> frame to the top/left corner of the screen here.
>
> IIUC C-x r f runs the command 'frameset-to-register' which stores a
> "framset" in a register.  C-x r j runs the command 'jump-to-register'
> which does _not_ restore a frame's state via 'frameset--restore-frame'
> but goes to 'set-frame-configuration' instead.  Apparently, framesets
> and frame configurations differ in a couple of minor aspects and the
> fullscreen state is one of them.

They do, but when edebugging jump-to-register, I end up in this branch
of the cond:

     ((registerv-p val)
      (cl-assert (registerv-jump-func val) nil
              "Don't know how to jump to register %s"
              (single-key-description register))
      (funcall (registerv-jump-func val) (registerv-data val)))

Which ends up calling frameset--restore-frame, so the problem is elsewhere.

>> Neither of those make any difference for me, nor does using
>> toggle-frame-maximized.
>
> Obviously so because 'frameset--restore-frame' does not get called in
> the first place.

I think I tested the wrong thing, probably because I forgot an
'eval-defun' somewhere.

The code that causes the frame to be restored in the wrong place is
this:

    (modify-frame-parameters frame
			     (if (eq (frame-parameter frame 'fullscreen) fullscreen)
				 ;; Workaround for bug#14949
				 (assq-delete-all 'fullscreen filtered-cfg)
			       filtered-cfg))

in framset--restore-frame, which means Iʼm going to have to break out
gdb and/or printf. (Iʼm surprised Eli is seeing this on MS-Windows
though, I thought the low-level frame implementation was completely
separate)

Robert

bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen

[martin rudalics]

 >> IIUC C-x r f runs the command 'frameset-to-register' which stores a
 >> "framset" in a register.  C-x r j runs the command 'jump-to-register'
 >> which does _not_ restore a frame's state via 'frameset--restore-frame'
 >> but goes to 'set-frame-configuration' instead.  Apparently, framesets
 >> and frame configurations differ in a couple of minor aspects and the
 >> fullscreen state is one of them.
 >
 > They do, but when edebugging jump-to-register, I end up in this branch
 > of the cond:
 >
 >       ((registerv-p val)
 >        (cl-assert (registerv-jump-func val) nil
 >                "Don't know how to jump to register %s"
 >                (single-key-description register))
 >        (funcall (registerv-jump-func val) (registerv-data val)))
 >
 > Which ends up calling frameset--restore-frame, so the problem is elsewhere.

Aha.  I have no idea how to debug these cl-forms so I usually end up
in some sort of nirvana.  On Windows I call WM_EMACS_SETWINDOWPOS (in
my_set_window_pos) with

   x = 902,
   y = 18,
   cx = 0,
   cy = 0,

and Windows gets back to me with a WM_MOVE for (0, 0) - the values
offered by GetWindowRect being

   left = 0,
   top = 0,
   right = 680,
   bottom = 658

I have no idea what to learn from this: (902, 18) is the correct
request and I see no intervening action from there until Windows
returns (0, 0).

 > The code that causes the frame to be restored in the wrong place is
 > this:
 >
 >      (modify-frame-parameters frame
 > 			     (if (eq (frame-parameter frame 'fullscreen) fullscreen)
 > 				 ;; Workaround for bug#14949
 > 				 (assq-delete-all 'fullscreen filtered-cfg)
 > 			       filtered-cfg))
 >
 > in framset--restore-frame, which means Iʼm going to have to break out
 > gdb and/or printf.

And removing the special fullsreen handling doesn't change anything?
Maybe we _should_ do something special when a fullscreen frame is
restored to a non-fullscreen one.

Basically, Emacs has been doing something inherently wrong all the
time: It asks to resize a frame while that frame is in fullscreen (or
maximized) state.  The correct interpretation on behalf of the window
manager would be to store the new sizes and apply them when the frame
is returned to its normal (non-fullscreen/non-maximized) state, IMHO.
For some reason, the approach chosen by Emacs has worked so I never
tried to fiddle with it.  But maybe it bites us this time.

 >(Iʼm surprised Eli is seeing this on MS-Windows
 > though, I thought the low-level frame implementation was completely
 > separate)

I see this on Windows too.  Normally, buggy behavior consistent across
platforms is an asset.  For some reason, this doesn't apply here yet.

martin

bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> Which ends up calling frameset--restore-frame, so the problem is elsewhere.
>
> Aha.  I have no idea how to debug these cl-forms so I usually end up
> in some sort of nirvana.  On Windows I call WM_EMACS_SETWINDOWPOS (in
> my_set_window_pos) with
>
>   x = 902,
>   y = 18,
>   cx = 0,
>   cy = 0,
>
> and Windows gets back to me with a WM_MOVE for (0, 0) - the values
> offered by GetWindowRect being
>
>   left = 0,
>   top = 0,
>   right = 680,
>   bottom = 658
>
> I have no idea what to learn from this: (902, 18) is the correct
> request and I see no intervening action from there until Windows
> returns (0, 0).
>

Thatʼs similar to what Iʼm seeing. gtk_window_move is called with the
right parameters, but the frame ends up in the wrong place.

>> The code that causes the frame to be restored in the wrong place is
>> this:
>>
>>      (modify-frame-parameters frame
>> 			     (if (eq (frame-parameter frame 'fullscreen) fullscreen)
>> 				 ;; Workaround for bug#14949
>> 				 (assq-delete-all 'fullscreen filtered-cfg)
>> 			       filtered-cfg))
>>
>> in framset--restore-frame, which means Iʼm going to have to break out
>> gdb and/or printf.
>
> And removing the special fullsreen handling doesn't change anything?
> Maybe we _should_ do something special when a fullscreen frame is
> restored to a non-fullscreen one.

If I understand that code, it says "if the old and new fullscreen
states are the same, donʼt pass fullscreen to modify-frame-parameters"
(itʼs Friday afternoon, I may be wrong, and the fullscreen variable
there has an unhelpful name :-) )

> Basically, Emacs has been doing something inherently wrong all the
> time: It asks to resize a frame while that frame is in fullscreen (or
> maximized) state.  The correct interpretation on behalf of the window
> manager would be to store the new sizes and apply them when the frame
> is returned to its normal (non-fullscreen/non-maximized) state, IMHO.
> For some reason, the approach chosen by Emacs has worked so I never
> tried to fiddle with it.  But maybe it bites us this time.

So youʼre saying we should un-maximize, and then set the frame size
afterwards? The patch below tries that, it works for me, although it
does of course cause the frame to resize and then move in two steps.

>>(Iʼm surprised Eli is seeing this on MS-Windows
>> though, I thought the low-level frame implementation was completely
>> separate)
>
> I see this on Windows too.  Normally, buggy behavior consistent across
> platforms is an asset.  For some reason, this doesn't apply here yet.

It turns our that most of the code is common, only the implementations
of things like x_set_offset and x_calc_absolute_position are
platform-specific. Iʼm still surprised they share the same bugs.

Robert

diff --git i/lisp/frame.el w/lisp/frame.el
index 29c31f41cb..a58fad6481 100644
--- i/lisp/frame.el
+++ w/lisp/frame.el
@@ -2413,7 +2413,7 @@ toggle-frame-maximized
      (t
       (set-frame-parameter nil 'fullscreen 'maximized)))))
 
-(defun toggle-frame-fullscreen ()
+(defun toggle-frame-fullscreen (&optional frame)
   "Toggle fullscreen state of selected frame.
 Make selected frame fullscreen or restore its previous size if it
 is already fullscreen.
@@ -2431,14 +2431,14 @@ toggle-frame-fullscreen
 
 See also `toggle-frame-maximized'."
   (interactive)
-  (let ((fullscreen (frame-parameter nil 'fullscreen)))
+  (let ((fullscreen (frame-parameter frame 'fullscreen)))
     (if (memq fullscreen '(fullscreen fullboth))
-	(let ((fullscreen-restore (frame-parameter nil 'fullscreen-restore)))
+	(let ((fullscreen-restore (frame-parameter frame 'fullscreen-restore)))
 	  (if (memq fullscreen-restore '(maximized fullheight fullwidth))
-	      (set-frame-parameter nil 'fullscreen fullscreen-restore)
-	    (set-frame-parameter nil 'fullscreen nil)))
+	      (set-frame-parameter frame 'fullscreen fullscreen-restore)
+	    (set-frame-parameter frame 'fullscreen nil)))
       (modify-frame-parameters
-       nil `((fullscreen . fullboth) (fullscreen-restore . ,fullscreen))))
+       frame `((fullscreen . fullboth) (fullscreen-restore . ,fullscreen))))
     ;; Manipulating a frame without waiting for the fullscreen
     ;; animation to complete can cause a crash, or other unexpected
     ;; behavior, on macOS (bug#28496).
diff --git i/lisp/frameset.el w/lisp/frameset.el
index 0e3363d7ae..ffbf6722a7 100644
--- i/lisp/frameset.el
+++ w/lisp/frameset.el
@@ -1085,6 +1085,11 @@ frameset--restore-frame
       (when (frame-live-p parent-frame)
         (set-frame-parameter frame 'parent-frame parent-frame)))
 
+    (let ((old-fullscreen (frame-parameter frame 'fullscreen)))
+      (and (not (eq old-fullscreen fullscreen))
+           (memq old-fullscreen '(fullscreen fullboth))
+           (not fullscreen)
+           (toggle-frame-fullscreen frame)))
     (modify-frame-parameters frame
 			     (if (eq (frame-parameter frame 'fullscreen) fullscreen)
 				 ;; Workaround for bug#14949

bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen

[martin rudalics]

I found a simpler scenario: With emacs -Q do C-x r f a, drag the frame
somewhere else on your screen and do C-x r j a.  Here the registered
position is restored.  Now do C-x r f a, drag the frame somewhere
else, do F11 and C-x r j a.  Here the frame is restored to the
position it had before F11 and not to the one registered by C-x r f a.

So this time it seems that I have the right explanation: We first
position the frame according to the position from the register and
then demaximize it.  But we should first demaximize and then
reposition it.  Can you confirm?

martin

bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

> I found a simpler scenario: With emacs -Q do C-x r f a, drag the frame
> somewhere else on your screen and do C-x r j a.  Here the registered
> position is restored.  Now do C-x r f a, drag the frame somewhere
> else, do F11 and C-x r j a.  Here the frame is restored to the
> position it had before F11 and not to the one registered by C-x r f a.
>

I confirm this exact behaviour under GTK.

> So this time it seems that I have the right explanation: We first
> position the frame according to the position from the register and
> then demaximize it.  But we should first demaximize and then
> reposition it.  Can you confirm?

That looks like it. The patch I sent earlier fixes it for me, but Iʼm
not sure itʼs the right solution, it feels very heavyweight.

Robert

bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen

[martin rudalics]

 > That looks like it. The patch I sent earlier fixes it for me, but Iʼm
 > not sure itʼs the right solution, it feels very heavyweight.

I think so too (note that we already have
'x-frame-normalize-before-maximize' to achieve a similar effect).  The
fix should be probably in 'frameset-restore' but so far I'm still too
silly to even debug that function.

martin

bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen

[Spenser Truex]

Robert Pluim <rpluim@gmail.com> writes:

> diff --git i/lisp/frame.el w/lisp/frame.el
> index 29c31f41cb..a58fad6481 100644
> --- i/lisp/frame.el
> +++ w/lisp/frame.el
> @@ -2413,7 +2413,7 @@ toggle-frame-maximized
>       (t
>        (set-frame-parameter nil 'fullscreen 'maximized)))))
>
> -(defun toggle-frame-fullscreen ()
> +(defun toggle-frame-fullscreen (&optional frame)
>    "Toggle fullscreen state of selected frame.
>  Make selected frame fullscreen or restore its previous size if it
>  is already fullscreen.
> @@ -2431,14 +2431,14 @@ toggle-frame-fullscreen
>
>  See also `toggle-frame-maximized'."
>    (interactive)
> -  (let ((fullscreen (frame-parameter nil 'fullscreen)))
> +  (let ((fullscreen (frame-parameter frame 'fullscreen)))
>      (if (memq fullscreen '(fullscreen fullboth))
> -	(let ((fullscreen-restore (frame-parameter nil 'fullscreen-restore)))
> +	(let ((fullscreen-restore (frame-parameter frame 'fullscreen-restore)))
>  	  (if (memq fullscreen-restore '(maximized fullheight fullwidth))
> -	      (set-frame-parameter nil 'fullscreen fullscreen-restore)
> -	    (set-frame-parameter nil 'fullscreen nil)))
> +	      (set-frame-parameter frame 'fullscreen fullscreen-restore)
> +	    (set-frame-parameter frame 'fullscreen nil)))
>        (modify-frame-parameters
> -       nil `((fullscreen . fullboth) (fullscreen-restore . ,fullscreen))))
> +       frame `((fullscreen . fullboth) (fullscreen-restore . ,fullscreen))))
>      ;; Manipulating a frame without waiting for the fullscreen
>      ;; animation to complete can cause a crash, or other unexpected
>      ;; behavior, on macOS (bug#28496).
> diff --git i/lisp/frameset.el w/lisp/frameset.el
> index 0e3363d7ae..ffbf6722a7 100644
> --- i/lisp/frameset.el
> +++ w/lisp/frameset.el
> @@ -1085,6 +1085,11 @@ frameset--restore-frame
>        (when (frame-live-p parent-frame)
>          (set-frame-parameter frame 'parent-frame parent-frame)))
>
> +    (let ((old-fullscreen (frame-parameter frame 'fullscreen)))
> +      (and (not (eq old-fullscreen fullscreen))
> +           (memq old-fullscreen '(fullscreen fullboth))
> +           (not fullscreen)
> +           (toggle-frame-fullscreen frame)))
>      (modify-frame-parameters frame
>  			     (if (eq (frame-parameter frame 'fullscreen) fullscreen)
>  				 ;; Workaround for bug#14949
>
>
>
>

I've just discovered this bug for myself, without any register
manipulation. Here is the recipe (almost the same as the original):

1) Make a window and use the WM to make it 1/2 the screen size. I
usually grab the window with the mouse and hit it against the right side
of the screen.
2) F11 to toggle fullscreen.
3) do #2 again.

Now the window isn't perfectly 1/2 the window.

Checking the value of (frame-parameter nil 'fullscreen) produces the
symbol fullheight, which indicates the problem: the emacs restore
procedure (fullscreen-restore) only stores *some* information about the
previous window configuration. The following diff shows the workaround I
was using so I could happily use f11 with my emacs:
--- lisp/frame.el	2019-06-30 21:42:29.257939995 -0700
+++ lisp/frame.el	2019-06-30 21:41:34.239940756 -0700
@@ -2621,21 +2621,21 @@
 `frame-resize-pixelwise' to non-nil in order to make a frame
 appear truly fullscreen.  In addition, you may have to set
 `x-frame-normalize-before-maximize' in order to enable
 transitions from one fullscreen state to another.

 See also `toggle-frame-maximized'."
   (interactive)
   (let ((fullscreen (frame-parameter frame 'fullscreen)))
     (if (memq fullscreen '(fullscreen fullboth))
 	(let ((fullscreen-restore (frame-parameter frame 'fullscreen-restore)))
-	  (if (memq fullscreen-restore '(maximized fullheight fullwidth))
+	  (if (memq fullscreen-restore '(maximized))
 	      (set-frame-parameter frame 'fullscreen fullscreen-restore)
 	    (set-frame-parameter frame 'fullscreen nil)))
       (modify-frame-parameters
        frame `((fullscreen . fullboth) (fullscreen-restore . ,fullscreen))))
     ;; Manipulating a frame without waiting for the fullscreen
     ;; animation to complete can cause a crash, or other unexpected
     ;; behavior, on macOS (bug#28496).
     (when (featurep 'cocoa) (sleep-for 0.5))))

 \f

So I just threw out all width and height information. To do a proper
fix, I think Emacs needs to keep track of sufficient information about
the window. Window height, width, and location must be stored. The
current one only stores height or width.

This way the window manager seems to be able to make all the decisions
about window size, though I actually have no idea what is going on.

For toggle-frame-maximized the problem still exists though, and I have
not found any workaround.

--
Spenser Truex

bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen

[Eli Zaretskii]

> Date: Thu, 21 Jun 2018 09:16:24 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
>  > 1. save a frameset with an unmaximized frame
>  > start from emacs -Q
>  > create a second window with `C-x 2'
>  > use the mouse to move the frame to the right side of the desktop
>  > save the split window frame with `C-x r f a'
>  >
>  > 2. save a frameset with a maximized/fullscreen frame
>  > delete one of the windows with `C-x 1'
>  > press `f11' to make the frame fullscreen
>  > save the fullscreen frame with `C-x r f b'
>  >
>  > 3. restore the unmaximized frameset with `C-x r j a'
>  > After jumping between framesets from register b to register a, the
>  > non-fullscreen frame appears on the opposite (left) side of the desktop
>  > than it was originally. Typing `C-x r j a' a second time moves the frame
>  > to its original location.
>  >
>  > I've reproduced this using Emacs 26.1 in both Windows 10 and Fedora 28
>  > KDE desktop environments.
>  >
>  > In GNU Emacs 26.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.22.30)
>  >   of 2018-06-04 built on buildvm-10.phx2.fedoraproject.org
> 
> Thanks for the report.  Here I can't reproduce the behavior you
> observe on Windows XP even if I modify your recipe in various ways.
> Maybe someone else can give it a try.

I can reproduce here if I do "C-x r j a" then "C-x r j b", then "C-x r
j a" again.  The second time the frame split into two windows appears
at the left side of the desktop.

bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen

[martin rudalics]

 > I can reproduce here if I do "C-x r j a" then "C-x r j b", then "C-x r
 > j a" again.  The second time the frame split into two windows appears
 > at the left side of the desktop.

Indeed.  Splitting the window is not needed, BTW.

martin