Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 445392 - kde-base/konsole-4.9.3, x11-terms/xterm: backgroundcolor is not reset when scrolling
Summary: kde-base/konsole-4.9.3, x11-terms/xterm: backgroundcolor is not reset when sc...
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo KDE team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-30 20:44 UTC by Toralf Förster
Modified: 2014-03-29 18:34 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
screen shot (eix.jpeg,155.13 KB, image/jpeg)
2012-11-30 20:44 UTC, Toralf Förster
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Toralf Förster gentoo-dev 2012-11-30 20:44:14 UTC
Created attachment 331082 [details]
screen shot

Look at the screen shot - it works well, if I started a new terminal or when I run "clear" before.
But if eix has to scroll during it output then the background colour (at least here in the KOnsole in KDE 4.9.3) is wrongly reseted, meaning that after the PS1 prompt the back ground colour is wrong.
Comment 1 Anton Bolshakov 2012-12-01 03:09:34 UTC
this is a dup of the bug #438076
Comment 2 Martin Väth 2012-12-01 11:27:41 UTC
This is not related with eix:

printf '\033[43mCOLOR\n\e[0mNOCOLOR\n'

is interpreted falsely in konsole-4.9.3 when scrolling is needed.
Comment 3 Toralf Förster gentoo-dev 2012-12-01 14:47:03 UTC
(In reply to comment #2)
> This is not related with eix:
> 
> printf '\033[43mCOLOR\n\e[0mNOCOLOR\n'
> 
> is interpreted falsely in konsole-4.9.3 when scrolling is needed.

? - xterm fails in the same way here
Comment 4 Martin Väth 2012-12-01 20:25:30 UTC
(In reply to comment #3)
> ? - xterm fails in the same way here

You are right: I had tmux running when I tested which does not have this bug.

The problem is that if the background color has temporarily changed and a new line is scrolled in (for whatever reason: a newline or a line wider than the terminal width; both only if you are at the last line of the terminal) then the background color for the *whole* new line becomes the termporary background color.

I still consider this behavior a bug: the same escape sequences cause whole line-tails to have different colors, depending on the width of the terminal and depending on whether scrolling is necessary.

However, since several terminals suffer from the same bug, this seems to be a bug "by tradition" - apparently, eix is the first application stressing the background color so much that this bug becomes evident.

I am not sure what to do.

Certainly, I will add workarounds to eix by resetting background colors before sending linefeeds, but this still breaks if lines longer than the terminal width are output: This is only a workaround and not a true bugfix.

The following example demonstrates the problem:
Let the following run in the _last line_ of a 80-character wide konsole:

printf '\033[43m%81s\033[44m \033[0m\n'

Compare this when you replace 81 by 80 and by 70, respectively:
Only the latter corresponds to the (correct) result which you see if you run the command in the first line of an xterm or console.
Comment 5 Johannes Huber gentoo-dev 2013-05-02 09:03:43 UTC
How about to report this to upstream or is this a gentoo exclusive problem?
Comment 6 Thomas Dickey 2013-05-03 08:18:40 UTC
It's simple to state, subtle in the way it works.
Aside from ensuring that terminals implement bce
consistently (and that applications have the same
understanding), I don't see a way to address your
concerns.
Comment 7 Johannes Huber gentoo-dev 2013-11-23 16:46:19 UTC
(In reply to Thomas Dickey from comment #6)
> It's simple to state, subtle in the way it works.
> Aside from ensuring that terminals implement bce
> consistently (and that applications have the same
> understanding), I don't see a way to address your
> concerns.

I dont see a packaging issue here. Please report upstream we cant much do about it.
Comment 8 Chris Reffett gentoo-dev Security 2014-03-29 18:14:34 UTC
Upstream problem, please report there.