Previous output leeches through to nvim w/ WebGL Addon enabled

[AlexMordred]

Previous commands' output leeches through to nvim. The old output is only visible on the same lines you see the nvim prompt text - see screenshot. Doesn't happen with other editors, tried vi, nano, micro. Only happens when using the WebGL Addon.

Details

• Browser and browser version: Firefox 101.0.1
• OS version: Linux 5.15.49-1-MANJARO
• xterm.js version: latest

Steps to reproduce

1. Run some commands until at least half of your screen is filled with output bottom to top
2. Run nvim

[Tyriar]

I've spotted something similar recently as well

[Tyriar]

These dots are what I've seen sometimes:

I don't know the repro and I can't repro with nvim on macOS or Windows.

[AlexMordred]

@Tyriar I don't know much about terminals, but mine is a default Manjaro Linux terminal and yours looks customized (.bashrc?), I guess that makes a difference too.

[Tyriar]

@AlexMordred good point, I'll check without the fancy prompt

[Tyriar]

We're a bit too busy to action this issue in July

[Tyriar]

I don't have a Linux machine but I tested on the latest master of xterm.js on macOS in Firefox and Edge and seems to work fine. Some more information that could help:

• echo $PS1 result
• Set log level to debug and provide the logs when reproducing

[AlexMordred]

$ echo $PS1
\[\033[01;32m\][\u@\h\[\033[01;37m\] \W\[\033[01;32m\]]\$\[\033[00m\]

Not sure I understand the second part

[Tyriar]

@AlexMordred you an turn debug logs on which get send to the devtools console by running term.options.logLevel = 'debug'

[JasonXJ]

Hi, I believe I have hit the same bug, although the symtom is a bit different. And I have a way to reliably reproducing it on either xterm.js 4.19.0 (webgl addon 0.12.0) or vscode 1.70.2 (linux) when webgl is enabled (canvas without webgl does not have the same issue). Neovim version is 0.7.2.

$ echo '\u26a1\u26a1123' | tee /tmp/test
$ nvim -u NONE /tmp/test

And when you are in neovim, do this, A<esc>A<esc>:q!. On the status line, you will see this:

The text INSERT -- should have been cleared (it is cleared when webgl is disabled).

---

(Ignore the followings. It seems that using the unicode11 addon solves it)

I also see another issue in my xterm.js but not in vscode --- my \u26a1 is displayed one-char wide although neovim seems to consider it two-char wide (see the cursor position in this screenshot):

vscode seems to always display it two-char wide:

This does not seem to be affected by the font-family or whether webgl is enabled. Do you know why?

[JasonXJ]

I also find a way to repro a rendering error similar to this comment. I think it is actually an issue different from the one in my last comment.

So, you can trigger this error by:

• create a file with box drawing symbols \u2592 (e.g. python3 -c 'print("\u2592"*20)' > /tmp/boxes);
• use vim to open it (I don't think it actually has anything to do with vim though)
• Move the cursor back and forth
• You might need to switch the color scheme to see the rendering error.

[JasonXJ]

So, there are actually two different bugs mentioned here: 1) the issue mentioned by OP and this comment, where some texts are not cleared correctly and 2) Rendering artefects (e.g. dots) on the cursor canvas.

I figured out what is wrong with 1. It can happen when neovim sets some colors and then deletes some characters, and this is what happens inside the WebglRenderer:

• setColors() is called, and it clears this._model but not this._glyphRenderer.
• _updateModel() is called to update this._model to match the terminal buffer. Because this._model was cleared earlier, the code here thinks that the cell is up-to-date and there is no need to update this._glyphRenderer.

I think the correct fix for this is to make sure we clear this._glyphRenderer when we clear this._model. I will send a pull request soon.

[Tyriar]

I think this is fixed as both of @JasonXJ's PRs were merged. Correct me if I'm wrong 🙂

[deadb0d4]

@Tyriar that's a silly question, but when do you roughly expect these changes to be in vscode (stable version)?

[Tyriar]

@deadb0d4 I think this was landing in 1.72 (early October)