Bug 223027 - after update to xterm-223-1,internal border draws in random colors
Summary: after update to xterm-223-1,internal border draws in random colors
Alias: None
Product: Fedora
Classification: Fedora
Component: xterm
Version: 5
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Miroslav Lichvar
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-01-17 16:39 UTC by Chris Elmquist
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-02-06 17:19:35 UTC
Type: ---

Attachments (Terms of Use)

Description Chris Elmquist 2007-01-17 16:39:03 UTC
Description of problem:
after yum update to xterm-223-1 on 1/16/07, I found that the internal border
(which is the space between the chars and the window border) began to draw in
random colors each time the desktop is refreshed.  Previously, this border was
always black (or the same as the window background color).

Version-Release number of selected component (if applicable):

Name        : xterm
Version     : 223
Release     : 1.fc5

How reproducible:

each time desktop is refreshed (such as by switching virtual desktop away and
back), the internal border will be drawn in a random color.  Sometimes the color
is the same as the window background and all appears OK but majority of time,
color is white, blue, grey, etc.

Steps to Reproduce:
1. invoke xterm and run mutt in it
2. swap desktop to second virtual desktop and back
Actual results:

internal border shows up blue, white, grey, random colors other than window

Expected results:

internal border should be same color as window background thereby not being

Additional info:

both xterm and xorg-x11-server-Xorg-1.0.1-9.fc5.6 were updated at the same
time on 1/16/07.  It is possible this problem lies in the x11-server also
but I am unable to isolate without a method to revert one or the other of
these components.  Wish yum had a way to revert to previous version of
any particular package.

Comment 1 Miroslav Lichvar 2007-01-17 17:19:33 UTC
It's a bug in xterm, xterm-222 doesn't show this problem. CCing upstream maintainer.

Comment 2 Thomas E. Dickey 2007-01-17 18:14:05 UTC
yes (someone on Debian reported about a month ago, and it's
on my to-do list for #224).

Comment 3 Thomas E. Dickey 2007-01-18 01:11:36 UTC
I see the problem.  There's a simple fix in util.c, to
remove the comparison of color values in handle_translated_exposure:

RCS file: RCS/util.c,v
retrieving revision 1.313
diff -u -r1.313 util.c
--- util.c      2006/11/29 22:52:10     1.313 
+++ util.c      2007/01/18 01:09:22 
@@ -1433,9 +1433,7 @@ 
     y0 = (rect_y - OriginY(screen));
     y1 = (y0 + rect_height);
-    if (getXtermBackground(xw, xw->flags, xw->cur_background) != 
-       xw->core.background_pixel && 
-       (x0 < 0 || 
+    if ((x0 < 0 || 
         y0 < 0 ||
         x1 > Width(screen) ||
         y1 > Height(screen))) {

Making that part of the check work as intended is going to be much
more complicated.

Comment 4 Chris Elmquist 2007-01-18 01:49:08 UTC
Thanks guys.  I did confirm earlier today that my problem remained after
reverting the X server.  I then advanced the X server and reverted xterm
(to 215) and the problem went away.  I also experience the problem on FC6 and
reverting xterm there has fixed the problem too.

Comment 5 Thomas E. Dickey 2007-01-18 11:07:08 UTC
well yes - see my comments above.  Prior to #223,
xterm was not painting the inner border at all
(except in some special cases).  As part of Debian
#397642 (see the oldest note in
I added code to explicitly paint it.  However, the
X server optimized-out (or discarded) some of the
graphics state.  The fix noted above works around

Comment 6 Miroslav Lichvar 2007-01-18 15:08:35 UTC
Thanks. The patch is in xterm-223-2.fc5.

Comment 7 Leo Baltus 2007-02-06 17:14:39 UTC
Any chances of that patch getting in fc6?

Comment 8 Miroslav Lichvar 2007-02-06 17:19:35 UTC
Yes, it's in xterm-223-2.fc6.

Note You need to log in before you can comment on or make changes to this bug.