GNU bug report logs - #55779
29.0.50; child frame

Previous Next

Full log

Message #14 received at 55779 <at> debbugs.gnu.org (full text, mbox):

From: drshapeless <drsl <at> drshapeless.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 55779 <at> debbugs.gnu.org
Subject: Re: bug#55779: 29.0.50; child frame
Date: Fri, 03 Jun 2022 22:56:04 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> drshapeless <drsl <at> drshapeless.com> writes:
>
>> To be clear, it was said to be a child frame redisplay bug, (by
>> minad). It was not the parent frame blocking the child frame, instead it
>> seems to be another child frame blocking the child frame.
>>
>> You may check out the github issue below, where I posted a couple photos
>> showing the bug.
>>
>> https://github.com/minad/corfu/issues/161
>
> Thanks.  That's very odd, the only parts of the GTK-specific child frame
> support to have changed recently are the parts involving WM frame
> synchronization.  What happens if you comment out all the calls to
> `gdk_x11_window_set_frame_sync_enabled' in xfns.c and xterm.c?

I have commented out 2 calls in xfns.c and 1 call in xterm.c. But the
issue persists. A bit more detailed observation is that, the size of the
blocking overlay (just call it overlay now) is related to the last
completion child frame.

For example, if the last child frame was 3-line tall, if the next child
frame is 5-line tall, only the first 3 lines are blocked.

And still, this behaviour cannot be observed other than building with
gtk. 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.