bug#49959: 28.0.50; Emacs got quasi freeze

[martin rudalics]

> With this pacth;
>
> commit 483c5e953c12a95382bef4a3b6769a680c32fe86
> Author: Martin Rudalics <rudalics@gmx.at>
> Date:   Wed May 5 10:26:32 2021 +0200
>
>      Fix two GTK3 event handling issues
>
>      * src/xterm.c (handle_one_xevent): For GTK3 PropertyNotify and
>      MapNotify events explicitly request the stored frame sizes when
>      the frame changes from iconified to a non-hidden state
>      (Bug#24526).  For Expose events do not change the frame's
>      visibility or iconified state.  For FocusIn events on GTK3 do
>      not apply the fix for Bug#42655.  The latter two changes are to
>      avoid that plain invisible frames get reported as iconified.
>
> Emacs has often got a quasi freeze, not perfect freeze but doesn't
> accept any openraion except quitting operation.
>
> Sorry for the report only.

I assume that you have bisected the sources and reverted the above
commit in order to be sure that it really is the culprit.  Right?

Did you also follow the discussions in Bug#48413 and Bug#48268?  Can you
observe any of the symptoms mentioned there (blank screens, no redraws)
on your system?  Do you have to, for example, switch desktops to make
the freeze happen?  Can you imagine anything "untypical" for Emacs users
in your editing behavior that could provoke the freezes?

In either case, can you try to isolate the part(s) of the above commit
that are responsible for the freezes - in the worst case we'll have to
make them optional then.  And maybe you could also try to build with
GTK2 (and ideally with Lucid) so we can tell whether these freezes are
toolkit dependent.

You can also try to set `frame-size-history' to some positive number and
look at the most recent entries after a freeze has been broken and post
here what `frame--size-history' prints.  Maybe they can give us some
clues.

Finally, please give us more details about how your Emacs is configured
and which desktop and window manager you use.

Thanks in advance, martin