bug#37986: emacsclient doesn't open a frame when waiting for input in the minibuffer

[Sébastien Chapuis]

This bug occurs on emacs master branch but it doesn't with emacs 26.2

Steps to reproduce:

terminal #1:

$ git clone --recursive git://git.savannah.gnu.org/emacs.git

$ cd emacs && ./autogen.sh

$ mkdir build && cd build

$ ../configure --prefix=/opt/emacs-git --with-modules --with-xwidgets --with-imagemagick

$ make install

$ /opt/emacs-git/bin/emacs --fg-daemon -Q

Open another terminal (terminal #2):

$ /opt/emacs-git/bin/emacsclient -n -c BIG_FILE.txt

the command doesn't return and no frame is opened.

On the terminal #1, there is this output:

```

Warning: due to a long standing Gtk+ bug
https://gitlab.gnome.org/GNOME/gtk/issues/221
Emacs might crash when run in daemon mode and the X11 connection is unexpectedly lost.
Using an Emacs configured with --with-x-toolkit=lucid does not have this problem.
Starting Emacs daemon.
File BIG_FILE.txt is large (11.9 MiB), really open? (y)es or (n)o or (l)iterally
File BIG_FILE.txt is large (11.9 MiB), really open? (y)es or (n)o or (l)iterally 

```

Open a 3rd terminal (terminal #3):

$ /opt/emacs-git/bin/emacsclient -n -c

A new frame is opened with this message in the minibuffer:

`File BIG_FILE.txt is large (11.9 MiB), really open? (y)es or (n)o or (l)iterally`

If I type `y`, a new frame is opened (from terminal #2) with the file BIG_FILE.txt in its buffer.

Let me know if you need more details.

Thanks,

Sebastien Chapuis.