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.