bug#34680: Display monitor frames not warmed up

bug#34680: Display monitor frames not warmed up

[Juri Linkov]

Sometimes desktop restoration fails with the error:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  +(nil nil -1)
  frameset-move-onscreen(#<frame emacs@localhost 0x55a7cd486ed0> t)
  frameset--restore-frame(... t)
  frameset-restore([frameset ...] :reuse-frames t :cleanup-frames t :force-display t :force-onscreen t)
  desktop-restore-frameset()
  desktop-read()
  run-hooks(after-init-hook delayed-warnings-hook)
  command-line()
  normal-top-level()

because ‘frame-monitor-attributes’ in ‘frameset-move-onscreen’ returns ‘nil’.

It returns ‘nil’ because the attribute ‘frames’ returned by
‘display-monitor-attributes-list’ is empty, and ‘frame-monitor-attributes’
filters out the returned attributes if it can't find the arg ‘frame’ in
the list of frames.

However, when ‘display-monitor-attributes-list’ is “warmed up” with just
a ‘message’ call before its first call, its returned ‘frames’ contains
the arg ‘frame’.

I guess calling the function ‘message’ before calling ‘display-monitor-attributes-list’
performs some redisplay that adds the frame to the list of frames in
‘display-monitor-attributes-list’.

bug#34680: Display monitor frames not warmed up

[Juri Linkov]

> I guess calling the function ‘message’ before calling
> ‘display-monitor-attributes-list’ performs some redisplay that adds
> the frame to the list of frames in ‘display-monitor-attributes-list’.

It also fixes the issue when using any of the following
‘redisplay’, ‘redraw-display’, ‘redraw-frame’, or just
‘display-monitor-attributes-list’ before calling
‘frame-monitor-attributes’ for the first time.

Just calling ‘display-monitor-attributes-list’ somehow “registers” the
frame in the list of frames, so the next call of ‘display-monitor-attributes-list’
returns the attribute ‘frames’ containing the frame.

This is not a real patch, it only demonstrates what changes
can fix this issue:

diff --git a/lisp/frameset.el b/lisp/frameset.el
index ac034ec82a..18fed46e97 100644
--- a/lisp/frameset.el
+++ b/lisp/frameset.el
@@ -879,7 +879,11 @@ frameset-move-onscreen
 When forced onscreen, frames wider than the monitor's workarea are converted
 to fullwidth, and frames taller than the workarea are converted to fullheight.
 NOTE: This only works for non-iconified frames."
+  ;; (redisplay)
+  ;; (redraw-display)
+  ;; (redraw-frame)
+  (display-monitor-attributes-list frame)
   (pcase-let* ((`(,left ,top ,width ,height) (cl-cdadr (frame-monitor-attributes frame)))
 	       (right (+ left width -1))
 	       (bottom (+ top height -1))
 	       (fr-left (frameset-compute-pos (frame-parameter frame 'left) left right))

bug#34680: Display monitor frames not warmed up

[Juri Linkov]

>> I guess calling the function ‘message’ before calling
>> ‘display-monitor-attributes-list’ performs some redisplay that adds
>> the frame to the list of frames in ‘display-monitor-attributes-list’.
>
> It also fixes the issue when using any of the following
> ‘redisplay’, ‘redraw-display’, ‘redraw-frame’, or just
> ‘display-monitor-attributes-list’ before calling
> ‘frame-monitor-attributes’ for the first time.
>
> Just calling ‘display-monitor-attributes-list’ somehow “registers” the
> frame in the list of frames, so the next call of ‘display-monitor-attributes-list’
> returns the attribute ‘frames’ containing the frame.

I can't explain this, but this is the minimal patch that fixes my
problem.  This dry run by calling gdk_display_get_monitor_at_window
ignores its first wrong return value, so its subsequent calls return
correct values.

diff --git a/src/xfns.c b/src/xfns.c
index a627b7e19e..9096595625 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -4943,6 +4943,7 @@ Internal use only, use `display-monitor-attributes-list' instead.  */)
 	  && !FRAME_TOOLTIP_P (f))
 	{
 	  GdkWindow *gwin = gtk_widget_get_window (FRAME_GTK_WIDGET (f));
+	  gdk_display_get_monitor_at_window (gdpy, gwin);
 
 #if GTK_CHECK_VERSION (3, 22, 0)
           for (i = 0; i < n_monitors; i++)

bug#34680: Display monitor frames not warmed up

[Juri Linkov]

>>> I guess calling the function ‘message’ before calling
>>> ‘display-monitor-attributes-list’ performs some redisplay that adds
>>> the frame to the list of frames in ‘display-monitor-attributes-list’.
>>
>> It also fixes the issue when using any of the following
>> ‘redisplay’, ‘redraw-display’, ‘redraw-frame’, or just
>> ‘display-monitor-attributes-list’ before calling
>> ‘frame-monitor-attributes’ for the first time.
>>
>> Just calling ‘display-monitor-attributes-list’ somehow “registers” the
>> frame in the list of frames, so the next call of ‘display-monitor-attributes-list’
>> returns the attribute ‘frames’ containing the frame.
>
> I can't explain this, but this is the minimal patch that fixes my
> problem.  This dry run by calling gdk_display_get_monitor_at_window
> ignores its first wrong return value, so its subsequent calls return
> correct values.

I discovered this is a known problem yet unfixed for many years:

  https://debbugs.gnu.org/19706
  25.0.50; (+ nil nil -1) in desktop-restore-frameset

with references from

  http://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00131.html
  http://lists.gnu.org/archive/html/emacs-devel/2017-01/msg00474.html

Although the original bug report was for macOS, the same bug I see is
for GDK on GNU/Linux.  At least, I found a fix for GDK that populates
the 'frames' attribute.  But if on macOS display-monitor-attributes-list
returns no 'frames' attribute, this feature is unavailable on macOS.

bug#34680: Display monitor frames not warmed up

[Juri Linkov]

>>>> I guess calling the function ‘message’ before calling
>>>> ‘display-monitor-attributes-list’ performs some redisplay that adds
>>>> the frame to the list of frames in ‘display-monitor-attributes-list’.
>>>
>>> It also fixes the issue when using any of the following
>>> ‘redisplay’, ‘redraw-display’, ‘redraw-frame’, or just
>>> ‘display-monitor-attributes-list’ before calling
>>> ‘frame-monitor-attributes’ for the first time.
>>>
>>> Just calling ‘display-monitor-attributes-list’ somehow “registers” the
>>> frame in the list of frames, so the next call of ‘display-monitor-attributes-list’
>>> returns the attribute ‘frames’ containing the frame.
>>
>> I can't explain this, but this is the minimal patch that fixes my
>> problem.  This dry run by calling gdk_display_get_monitor_at_window
>> ignores its first wrong return value, so its subsequent calls return
>> correct values.
>
> I discovered this is a known problem yet unfixed for many years:
>
>   https://debbugs.gnu.org/19706
>   25.0.50; (+ nil nil -1) in desktop-restore-frameset

As a last resort, I installed this patch as panacea for all such bugs:

diff --git a/lisp/frame.el b/lisp/frame.el
index c5802e30b6..7cfe546ca6 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -1696,7 +1696,10 @@ frame-monitor-attributes
   (or frame (setq frame (selected-frame)))
   (cl-loop for attributes in (display-monitor-attributes-list frame)
 	   for frames = (cdr (assq 'frames attributes))
-	   if (memq frame frames) return attributes))
+	   if (memq frame frames) return attributes
+	   ;; On broken frames monitor attributes,
+	   ;; fall back to the last monitor.
+	   finally return attributes))
 
 (defun frame-monitor-attribute (attribute &optional frame x y)
   "Return the value of ATTRIBUTE on FRAME's monitor.