[Bug] Background color bleeds on soft-wrapped lines after scroll

[zmberber]

Issue Description

Ghostty corrupts ANSI background color rendering when lines with multiple background colors scroll from the visible area into the scrollback buffer. After the scroll occurs, background colors on soft-wrapped lines bleed past \e[0m resets. Only \ec (RIS - Reset to Initial State) recovers, \e[0m (SGR reset) is insufficient.

This came to my attention when I used a powerline preset for the starship shell prompt. it is particularly annoying there with small terminal windows.

Expected Behavior

Lines render identically regardless of whether they are in the visible area or have scrolled into the scrollback. \e[0m fully resets all color attributes. Soft-wrapped lines respect color changes and resets after the wrap point.

Actual Behavior

1. Lines that fit within the visible terminal area render correctly.
2. Once lines scroll off the visible area into the scrollback buffer, subsequent lines exhibit background color bleed: the background color active at a soft wrap point fills the rest of the wrapped line, ignoring all subsequent color changes and \e[0m resets.
3. The exact line where the bug first appears depends on terminal height, it is always the line that first triggers a scroll.
4. The corruption persists for all subsequent output until \ec is issued.

Reproduction Steps

1. Save the following script (/tmp/colors.sh in the screenshot):

   #!/usr/bin/env bash
   for i in $(seq 1 30); do
     printf '%2d \e[41m%30s\e[0m\e[43m%30s\e[0m\e[42m%30s\e[0m\e[46m%30s\e[0m\e[44m%30s\e[0m\e[45m%30s\e[0m\e[101m%30s\e[0m\e[103m%30s\e[0m RESET\n' \
       "$i" RED YELLOW GREEN CYAN BLUE MAGENTA BRED BYELLOW
   done

2. Make the terminal narrow enough that the lines soft-wrap, but also such that the last line wrap does not happen within the RESET text, and such that the terminal window is less than 30 lines tall.
3. Run the script. Lines that fit in the visible area render correctly. The line that first causes a scroll (and all subsequent lines) shows background color bleeding past the resets, "RESET" text has a colored background.
4. Resize the terminal to a different height and run again, the bug starts at a different line number, always corresponding to when the first scroll occurs.
5. printf '\ec' clears the corrupted state.

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.1

Version
  - version: 1.3.1
  - channel: stable
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .gtk
  - font engine   : .fontconfig_freetype
  - renderer      : renderer.generic.Renderer(renderer.OpenGL)
  - libxev        : io_uring
  - kernel version: 6.18.21
  - desktop env   : gnome
  - GTK version   :
    build         : 4.20.3
    runtime       : 4.20.3
  - libadwaita    : enabled
    build         : 1.8.4
    runtime       : 1.8.4
  - libX11        : enabled
  - libwayland    : enabled

OS Version Information

Linux 6.18.21 #1-NixOS SMP PREEMPT_DYNAMIC x86_64

(Linux only) Display Server

Wayland

(Linux only) Desktop Environment/Window Manager

GNOME (Wayland)

Minimal Ghostty Configuration

# no config/standard config

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[ForsakenHarmony]

can reproduce on macos 26.3.1

Ghostty 1.3.1

Version
  - version: 1.3.1
  - channel: stable
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

[zmberber]

I have new insights. This does not seem to be specific to ghostty, but it is also not universal. Perhaps a common faulty ANSI code implentation issue? Is this a bug worth submitting elsewhere, or is this just an ANSI quirk that sometimes happens that i have to deal with? especially because it happens in xterm, perhaps this is just an old unix quirk one has to deal with?

The bug is reproducible in:

• wezterm
• konsole
• rio
• foot
• xterm

This bug is not an issue in:

• kitty
• terminator
• GNOME console (the reason why i initially thought it is ghostty-specific)

[zmberber]

ok, i found the issue, it has to do with bce (back color erase) not being implemented correctly or at all everywhere.

• https://unix.stackexchange.com/questions/212933/background-color-whitespace-when-end-of-the-terminal-reached
• https://stackoverflow.com/questions/53740460/ansi-escape-code-weird-behavior-at-end-of-line
• https://invisible-island.net/ncurses/ncurses.faq.html#bce_mismatches
• https://invisible-island.net/xterm/xterm.faq.html#bce_oddness
• https://invisible-island.net/ncurses/ncurses-slang.html#cause_bce_linux

[pluiedev]

Not an expert, but it reads to me that "correctness" isn't really the best word to use here? As the ncurses FAQ points out, the ECMA-48 standard itself is already not precise/prescriptive enough, so it's really up in the air as to what any terminal emulator should do. (The physical terminals most of us are emulating, namely VT100 and VT220s, don't deal with this, since they do not have color support as mentioned in the above sources.)

From our perspective, Ghostty's behavior is defined in terms of (in order of priority) what is specified in the ECMA-48 spec/other written specs for protocols from other terminal emulators e.g. Kitty (which as established is basically unspecified), then xterm's behavior, then general practice. Since in this case we agree with xterm, I don't really think there's anything we should change.

[j4james]

The physical terminals most of us are emulating, namely VT100 and VT220s, don't deal with this, since they do not have color support as mentioned in the above sources.

Note that there are a couple of hardware terminals with color support - most notably the VT525 - and it actually has a mode that allows apps to control this behaviour: DECECM (Erase Color Mode). As defined in the programmer documentation, "it controls the background color used when text is erased or new text is scrolled on to the screen". When set, these operations fill with the default attributes (compatible with monochrome terminals). When reset, they fill with the active rendition colors (which is compatible with most modern color terminal emulators). The factory default is reset, i.e. it fills with the active colors.

While DECECM isn't actually listed as a conformance requirement for the Color Text Extension, I think it would be a good idea for color terminals to a least report how they are implementing that mode in response to a DECRQM query (i.e. permanently reset if you always fill with the active colors, or permanently set if you always fill with the default attributes). That way apps can potentially adjust their behavior to match. Ideally I'd like to see more terminals fully support the mode, though, so apps can turn it on if they don't want the color background fill when scrolling.

[pluiedev]

Oh, that's cool. In that case I think we'll be open to set it to permanently reset so that apps have slightly more guarantees than before

[zmberber]

should we open an issue for this, perhaps?

[jcollie]

#12505