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

["Sébastien Chapuis" <sebastien@chapu.is>]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1937 bytes --]