ESC[0m won't reset colors if followed by new line

[CarterLi]

Explain what happens

echo -e '\033[41;31m!\033[0m\n'

Expected: (iTerm2)

Actual: (Cockpit)

Version of Cockpit

285

Where is the problem in Cockpit?

Terminal

Server operating system

Fedora

Server operating system version

Linux eoitek.net 6.2.0-0.rc8.20230217gitec35307e18ba.60.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Feb 17 16:19:48 UTC 2023 x86_64 GNU/Linux

What browsers are you using?

Chrome, Edge

System log

No response

[garrett]

This is not a Cockpit bug, but a terminal emulation bug.

We use xterm.js to render the console, specifically version 5.1.0 at the moment (this is the latest release), with the canvas addon that is version 0.3.0.

That said, VS Code also uses xterm.js — and I tested it in VS Codium and got this:

So at least one implementation is correct... but they're using a different renderer by default (at least on my system).

As VS Code uses Electron, I also tried Cockpit in Chrome (as they'd effectively use the same browser engine). The this bug still shows up in Cockpit's terminal:

But in VS Codium have "auto" as my renderer:

When I switch the renderer to "canvas", I see the bug in VS Codium too:

Here's the upstream issue @ xterm.js:

• Clearing formatting results in different background color for different renderers xtermjs/xterm.js#4120

We'll have to wait for upstream to fix this and we'll update the dependency when they do.

[CarterLi]

Let's wait for xterm.js change then

[CarterLi]

The new version of xterm has been released for several weeks. Does the problem still exist?

[martinpitt]

We can't update to xterm 5.2, as that breaks the accessibility tree: xtermjs/xterm.js#4571 .

[garrett]

xterm.js fixed the accessibility tree in the PR @ xtermjs/xterm.js#4637 — we should consider updating.

[jelly]

It's fixed in 5.3.0