After some more testing I got this to reproduce in Konsole.

Another data point: seems to reproduce only inside of tmux (2.6). But does not reproduce with tmux and xterm!

What distro are you using? Are you running that in yakuake?

 W/ tmux 2.1, it works as expected.

Company-internal distro based on Debian. I've encountered it in Yakuake, but then also managed to reproduce it in Konsole.

Took me a while to realize, so let's emphasize: In the screenshot, the first column is full of B's.

How reproducible is this?

What's the value of $TERM outside of tmux?

I believe the first big step in debugging would be to locate whether this is a bug in konsole/yakuake or tmux. I can easily imagine both, and not being able to reproduce in xterm could be due to different timing of things if it's a tmux issue.

Here's how I'd proceed:

- Take a note of the window size (e.g. "stty size").

- Start "script", and then start "tmux".

- Reproduce the bug in as few steps as possible.

- Quit tmux, then quit script (e.g. press ^D twice).

- Attach the resulting "typescript" file, and also share the window size with us.

- We could then manually investigate whether what appears in konsole's window matches the contents of "typescript" or not. By cutting off the end of the "typescript" file (the bits corresponding to exiting, most notably tmux leaving alternate screen) we should be able to deterministically reproduce the faulty result using a simple "cat typescript" at the same terminal size, and even do this in other terminal emulators. If by cat'ing typescript the result is the same in all terminal emulators, namely the bad rendering, then it's tmux asking for stupid things from konsole. If cat'ing is only broken in konsole, or is still random (e.g. depends on timing) then it's a konsole issue.

Created attachment 111196 [details]
typescript with bug triggered

Created attachment 111197 [details]
screenshot corresponding to above typescript

Thanks for the detailed instructions! I've attached the typescript to this bug.

Terminal size and TERM value:

% stty size
24 80
% printenv TERM
xterm-256color

I've tried cat'ing the copy of typescript with the ending removed and it still triggers the bug in Konsole, but xterm is fine.

Indeed, I can reproduce it now in konsole-17.04.3, by cat'ing with the end of the file removed (truncate -s 3276 typescript), the result is significantly different from xterm or vte.

Timing doesn't matter in konsole, slowcat'ing this file by inserting a 50ms pause between each byte (after compiling VTE: vte/src/slowcat -t 50000 typescript) produces the same output.

If timing makes a difference at all, as seen originally, it might be because tmux receives its stuff at different times and hence updates in different ways, all of which _should_ result in the same final look.

What triggers the problem in konsole is at byte offset 2810 of typescript.

To reproduce manually: Produce at least a screen of data, then execute:

echo -e "\e[1;23r\e[23S"

It sets up the scrolling region to rows 1-23 (that is, the bottom row, row 24 excluded) and asks to scroll by 23 lines. This should effectively clear those lines (and leave the bottom row intact), but it konsole it doesn't do anything.

I vaguely recall already having seen a bug report for this in konsole (it's buggy when the parameter to S [the number of lines to scroll by] is greater-than-or-equal-to the height of the scrolling area), but cannot find it now.

Bug 379318 is the one I was looking for. I suspect this is a duplicate. If so, it's already fixed.

Thanks! It seems that this is indeed a duplicate of bug 379318.

According to https://github.com/KDE/konsole/commit/7ff23512fd6c6af1dba87083446f85baf75e9c71 , earliest release that has the fix is 17.07.80.

*** This bug has been marked as a duplicate of bug 379318 ***