bug#44180: 28.0.50; Emacs frames won't redisplay unless resized

[Sascha Sadeghian]

Eli Zaretskii <eliz@gnu.org> wrote:
> Since the other frames are not really visible, treating them as
> iconified makes some sense.  But then I don't understand your original
> report: you said these frames are not updated, but since they are
> obscured, what does "updated" mean for them?

I am seeing similar behaviour with the i3 window manager.

Let’s say we start with an Emacs GTK window and an xterm window side by
side, so that each has 50% of the total screen width ("split" mode in
i3). If I switch to "tabbed" mode now and select the Emacs tab, the
Emacs frame is unresponsive, and its contents are not redrawn any more.

This didn’t happen before 2c0cd90083.

Here is a quick demo with emacs -Q:

  https://webterm.io/bug-gnu-emacs/44180-working.webm
  https://webterm.io/bug-gnu-emacs/44180-broken.webm

The bug can be reproduced with a single frame.

The confusing part is probably that for this frozen frame, keyboard
input is still working, so buffers can be edited, while the edits are
only visible in other, non-frozen frames (for example, a second
emacsclient frame showing the same buffers). The GTK menu and toolbar
are also not affected.

Hope this helps!