Unexpected behavior with colored background, wrapping, scroll, and partial lines

[AlliedEnvy]

While writing a program that uses background colors, I noticed a strange behavior in ghostty, where partial lines have an unexpected background color (screencap below).

It looks like the following circumstances are necessary:

• text with a colored background gets wrapped between two lines
• the 2nd line is partial (not full of text)
• the 2nd line has the background color reset to default by the end of the text
• the 2nd line caused the terminal to scroll

When these are met, the rest of the partial line has the same background color as the text that wrapped.
I expect the rest of the partial line to have the default background color.

I'm not familiar with the standards for this; perhaps this is intentional?
I've tested all the terminals on my box and ghostty, xterm, and cool-retro-term do this.
gnome-terminal, ptyxis, kitty, and tmux do not.
Not sure what Linux console does.

---

Minimized test case:

const std = @import("std");

pub fn main() !void {
    const stdout_file = std.io.getStdOut().writer();
    var bw = std.io.bufferedWriter(stdout_file);
    const stdout = bw.writer();

    // get terminal window size
    var wsz: std.os.linux.winsize = undefined;
    _ = std.os.linux.ioctl(1, std.os.linux.T.IOCGWINSZ, @intFromPtr(&wsz));

    // reset cursor with CSI 0m and print an initial dot
    try stdout.writeAll("\x1b[0m.");
    for (0..1) |_| {
        // write additional $COLUMNS-2 dots
        try stdout.writeByteNTimes('.', wsz.ws_col - 2);
        // write 2 dots with black on bright red
        // this will wrap and put the 2nd one on the next line
        // then reset cursor again
        try stdout.writeAll("\x1b[30;101m..\x1b[0m");
    }
    try stdout.writeAll(".\n\n");

    try bw.flush();
}

Save above as test.zig, run zig build-exe test.zig; reset and then ./test until the terminal scrolls a few times.
You can change the length of the loop to wsz.ws_row to show it in one invocation.

---

Results of the above in ghostty (in unaffected terminals it displays like the top lines, every time):

[AlliedEnvy]

A simpler test case:

printf '\e[999C\e[30;101m..\e[0m.\n'

[mitchellh]

I haven't verified this again recently, but I believe in xterm, any created newlines (i.e. \n) are styled according to the SGR state of the cursor at the time of the newline. This is something we have unit tested.

I know 100% this is true within scroll regions and for operations like delete lines or insert lines or erase characters and so on. I'm not 100% sure if this applies to scrollback generating lines.

In our case, we follow xterm's lead, so let me verify with xterm.

[mitchellh]

Verified with xterm, this is intended behavior.

[AlliedEnvy]

Understandable, thanks for checking. This feels weird in xterm too (since it only occurs with scrollback), but I get that ghostty wants to match it.