GNU bug report logs - #13123
24.2; Resizing frame partly resets background color

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13123 in the body.
You can then email your comments to 13123 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Quintus <quintus <at> quintilianus.eu>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.2; Resizing frame partly resets background color
Date: Sat, 08 Dec 2012 10:57:02 +0100

[Message part 1 (text/plain, inline)]

Hi there,

resizing the Emacs frame causes the background color that has been set
via a theme or directly via M-x set-background-color to be reset to a
default value, except for the parts with (visible or invisible) text on
it. Steps to reproduce:

1. Start Emacs
2. M-x set-background-color and choose any background colour you like
3. Resize the frame

The effect can be recovered by again doing M-x set-background-color or
reloading the current theme (until the next resize). See the attached
screenshots for a demonstration (order in which they were taken is
preresize - postresize - postreset).

This is 100% reproducible on my two machines here running 64-bit Arch
Linux with i3 as the window manager in an otherwise mostly XFCE
environment (i3 is a tiling window manager and as such resizes windows
all the time). Emacs is in both cases the stock emacs from the Arch
Linux repositories. The GTK theme in use is the Xfce/gtk-3.0 theme.

Greetings,
Marvin


In GNU Emacs 24.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.2)
 of 2012-11-18 on eric
Windowing system distributor `The X.Org Foundation', version 11.0.11300000
Configured using:
 `configure '--prefix=/usr' '--sysconfdir=/etc' '--libexecdir=/usr/lib'
 '--localstatedir=/var' '--with-x-toolkit=gtk3' '--with-xft'
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector
 --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2'
 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: de_DE.utf8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x s e t - b a c k g r o u n d - c o l <tab> <return>
# 0 0 0 0 F F <return> M-x r e p o r t - e m a c s
- b u <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
delete-backward-char: Text is read-only

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image
fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

[postreset.png (image/png, attachment)]

[postresize.png (image/png, attachment)]

[preresize.png (image/png, attachment)]

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

From: Chong Yidong <cyd <at> gnu.org>
To: Quintus <quintus <at> quintilianus.eu>
Cc: 13123 <at> debbugs.gnu.org
Subject: Re: bug#13123: 24.2; Resizing frame partly resets background color
Date: Fri, 21 Dec 2012 15:35:34 +0800

Quintus <quintus <at> quintilianus.eu> writes:

> resizing the Emacs frame causes the background color that has been set
> via a theme or directly via M-x set-background-color to be reset to a
> default value, except for the parts with (visible or invisible) text on
> it.
>
> This is 100% reproducible on my two machines here running 64-bit Arch
> Linux with i3 as the window manager in an otherwise mostly XFCE
> environment (i3 is a tiling window manager and as such resizes windows
> all the time). Emacs is in both cases the stock emacs from the Arch
> Linux repositories. The GTK theme in use is the Xfce/gtk-3.0 theme.
>
> In GNU Emacs 24.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.2)
>  of 2012-11-18 on eric

I can't reproduce this on GNU/Linux (Ubuntu 12.04), running GTK+ 3.4.2.
Maybe this is related to Bug#12448, which was also reported by someone
using Arch, running GTK+ 3.4.4.  Do you see the same problem with xfwm?

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

From: Quintus <quintus <at> quintilianus.eu>
To: Chong Yidong <cyd <at> gnu.org>
Cc: 13123 <at> debbugs.gnu.org
Subject: Re: bug#13123: 24.2; Resizing frame partly resets background color
Date: Sat, 22 Dec 2012 00:47:24 +0100

[Message part 1 (text/plain, inline)]

Am Fri, 21 Dec 2012 15:35:34 +0800
schrieb Chong Yidong <cyd <at> gnu.org>:

> Do you see the same problem with xfwm?

Yes, the problem is also there with xfwm, see attached screenshot. xfwm
--version says:

	This is xfwm4 version 4.10.0 (revision cc70567) for Xfce 4.10
	Released under the terms of the GNU General Public License.
	Compiled against GTK+-2.24.10, using GTK+-2.24.14.

	Build configuration and supported features:
	- Startup notification support:                 Yes
	- XSync support:                                Yes
	- Render support:                               Yes
	- Xrandr support:                               Yes
	- Embedded compositor:                          Yes
	- KDE systray proxy (deprecated):               No

> Maybe this is related to Bug#12448, which was also reported by
> someone using Arch, running GTK+ 3.4.4

It was actually me who filed this bug and then obviously forget about
it. Sorry!

GTK versions installed on my system are 2.24.14 and 3.6.2.

Vale,
Marvin

[xfwm.png (image/png, attachment)]

[signature.asc (application/pgp-signature, attachment)]

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

From: Chong Yidong <cyd <at> gnu.org>
To: Quintus <quintus <at> quintilianus.eu>
Cc: 13123 <at> debbugs.gnu.org
Subject: Re: bug#13123: 24.2; Resizing frame partly resets background color
Date: Sat, 22 Dec 2012 09:32:46 +0800

Quintus <quintus <at> quintilianus.eu> writes:

>> Do you see the same problem with xfwm?
>
> Yes, the problem is also there with xfwm, see attached screenshot.

Just to make sure this is not due to some customizations done by Arch
itself: did you start Emacs as `emacs -Q' before going through the bug
recipe?  Also, did you compile Emacs yourself or is it precompiled by
Arch?

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

From: Quintus <quintus <at> quintilianus.eu>
To: Chong Yidong <cyd <at> gnu.org>
Cc: 13123 <at> debbugs.gnu.org
Subject: Re: bug#13123: 24.2; Resizing frame partly resets background color
Date: Sat, 22 Dec 2012 09:22:17 +0100

[Message part 1 (text/plain, inline)]

Am Sat, 22 Dec 2012 09:32:46 +0800
schrieb Chong Yidong <cyd <at> gnu.org>:

> Quintus <quintus <at> quintilianus.eu> writes:
> 
> >> Do you see the same problem with xfwm?
> >
> > Yes, the problem is also there with xfwm, see attached screenshot.
> 
> Just to make sure this is not due to some customizations done by Arch
> itself: did you start Emacs as `emacs -Q' before going through the bug
> recipe?  

Ah, you’re right, for the xfwm test I didn’t use the -Q option. However,
doing so doesn’t change the situation, the effect is still the same.
The test on i3 was with -Q anyway.

> Also, did you compile Emacs yourself or is it precompiled by
> Arch?

This is the precompiled Emacs from Arch; I’ll try to reproduce the bug
with the current development version later today. For the time being,
here’s the build script Arch uses to compile Emacs:
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/emacs

No patches except for some chmod/chowns are applied to the source, so
this should be a quite vanilla Emacs.

Vale,
Marvin

[signature.asc (application/pgp-signature, attachment)]

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

From: Chong Yidong <cyd <at> gnu.org>
To: Quintus <quintus <at> quintilianus.eu>
Cc: 13123 <at> debbugs.gnu.org
Subject: Re: bug#13123: 24.2; Resizing frame partly resets background color
Date: Tue, 02 Apr 2013 09:53:54 +0800

I just installed an Arch system, and I can't reproduce the bug using the
precompiled Emacs 24.2.  I also compiled the emacs-24 branch:

  GNU Emacs 24.2.91.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.2)

I can't reproduce there either.  Window manager is latest xfwm.

Message #31 received at 13123-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: 13123-done <at> debbugs.gnu.org
Subject: Background not handled consistently
Date: Tue, 22 Apr 2014 22:39:38 -0400

Closing, since it seems we couldn't reproduce it and the
discussion died.
If you still can reproduce the problem with a recent Emacs build, please
re-open the bug.


        Stefan

Previous Next

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