bug#30019: 26.0.90; Invalid specification of parent-frame with desktop-read

[martin rudalics <rudalics@gmx.at>]

 >> In practice this means that with desktop in use I have to install some
 >> sort of hook or timer that triggers when the parent frame has been
 >> mapped and reparent the (until then probably hidden and not yet
 >> parented) child frame.
 >
 > I don't think I understand why you need this.  I thought you said that
 > we only need an X window when the minibuffer becomes active, or did I
 > misunderstand?  If I did understand correctly, then this problem
 > sounds like something that should be worked around by avoiding the
 > error, not something that needs to be fixed.  The parent frame will be
 > eventually mapped, most probably much sooner than the user uses the
 > minibuffer for the first time.  Right?

Normal minibuffer frames are top-level frames, they have no parent.
So we have no problems with minibuffer frames because the window
system will have created and made them visible some time before the
first user interaction occurs.

The problem here is with child frames whose window system parent
window can be assigned only after that parent window has been made by
the window system and whose identity has been reported to us.

martin