bug#48408: BUGFIX: window-default-font-height: check for nil string

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 19 May 2021 00:00:53 -0400
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: martin rudalics <rudalics@gmx.at>, 48408@debbugs.gnu.org
> 
> 1) In working on this bug, I noticed that the mode line on the GUI frame
>    was not correctly indicating the frame name. Should I file that as a
>    separate bug? Add it to some other current outstanding bug? Let it
>    stand as part of this report?

GUI frame or TTY frame?  GUI frames by default don't have names, you
need to give them a name if you want.

If all I said above doesn't help, then yes, please report a bug with
all the details.

> 2) Likewise, for more than two years I've intermittently been having a
>    'grave' emacs bug that I never reported on this list because I
>    couldn't ever figure out how to reproduce it. In working on this bug,
>    I seem to have figured out the problem (but not a solution):
> 
>    2.1) Whenever a minibuffer is active in one frame, the other windows
>         on that frame are navigable and operable. However, all elements
>         of all other frames are completely frozen.
> 
>    2.2) This most commonly seems to have been happening to me when
>         composing an email message using mutt, which I have configured
>         to use emacsclient as its editor.
> 
>    2.3) Up until now, my work-around has been to `pkill emacsclient` and
>         restart the client (this doesn't cause any data loss, since all
>         data is on the server).

It's a "feature": Emacs can read input only from one frame at a time.