rendering issues (unusable) on chrome 108 on pixel 7 pro

[donbowman]

I have tried this w/ webssh, w/ ttyd, and w/ tty-share (all apps using xtermjs) as well as NgTerminal (our own attempt to use). It works reliably on other devices, but something about the screen resolution/os/browser makes it unusable. It initially comes up ok, and you can touch a few keys and its fine. Then all of a sudden the screen goes black with 1 or 2 characters showing, and input/output are somewhat shown (e.g. type ${foo} and you will see $${{ }}), but nothing is usable.

in additon, perhaps related, when this happens the cursor goes green and what you type is also green. 2 screenshots attached (good and bad). The good is a bit distorted since its wider than my phone, but usable.

Details

• Browser and browser version: Chrome 108 (chrome beta)
• OS version: Android 13
• xterm.js version: latest

Steps to reproduce

Its more or less immediate. Pick any of webssh, ttyd, tty-share and use. As soon as i touch the screen it will usually distort, redrawing all incorrectly.

below is 'good' (yes its a bit distorted by width).

Below is 'bad'. Same screen as above, just have touched it on display.

[Tyriar]

Are you using the builtin DOM renderer or an addon? This could be https://github.com/xtermjs/xterm.js/pull/4271

[donbowman]

no addons. will examine that linked issue

[Tyriar]

xterm.js version: latest

No addons and this is on v5? If so I'm not sure what could be the issue here.

[donbowman]

in our code base we are using NgTerminal, which in turn calls xterm 4.19.0. It appears there are a couple of addons in the package-lock.json -xterm-addon-flt -xterm-addon-attach -xterm-addon-web-links

In the other xtermjs using sw i tried (https://github.com/tsl0922/ttyd), it uses:

import { CanvasAddon } from 'xterm-addon-canvas';
import { WebglAddon } from 'xterm-addon-webgl';
import { FitAddon } from 'xterm-addon-fit';
import { WebLinksAddon } from 'xterm-addon-web-links';
import { ImageAddon } from 'xterm-addon-image';
import { OverlayAddon } from './addons/overlay';
import { ZmodemAddon } from './addons/zmodem';

with export type RendererType = 'dom' | 'canvas' | 'webgl';

I also tried github.com/elisescu/tty-share

which uses "xterm": "^5.0.0"

it does not appear to have any addons or set render type.

[Tyriar]

If you're on 4.19.0 it will use the canvas renderer by default, in v5 the canvas renderer became an addon. So this happens in both?

[jerch]

Since it seems to fail with all renderer versions and different xterm.js versions - maybe this is the culprit: "Chrome 108 (chrome beta)"?

Edit: And from a more technical viewpoint - to me it seems highly unlikely that all renderer would expose the same faulty behavior, if the root cause is within them. Which raises the question, whether something more fundamental goes wrong here (eg. Chrome itself or even some OS graphics driver).

[donbowman]

So this is indeed on chrome beta... but it will be chrome stable soon enough :) its on stock install google pixel 7 pro, so no os graphics drivers etc can be installed or changed.

we are going to try updating the ngterminal dependency to latest xtermjs and do some more tests w/ our code w/ the various render options.

Also, i should note, the screen shots are taken from the chrome debugger running over usb to a linux machine. Since it also shows the incorrect value, i doubt its os graphics (since a readback would not see).

[donbowman]

ps, chrome 108 is no longer beta https://support.google.com/chrome/a/answer/7679408?hl=en

[jerch]

ps, chrome 108 is no longer beta https://support.google.com/chrome/a/answer/7679408?hl=en

And the issues are not gone I guess?

My reasoning why I think the root cause may not be in xterm.js itself:

• The 3 renderers use very different mechs to get something on the screen, which makes it almost impossible to get the same faulty output.
• We get reports of rendering issues here and there, but none so far that addresses all of them at once with the same faulty behavior.

Some outer possibilities, that would need further narrowing:

• Chrome version - Does it also happen with Chrome 108 on other platforms? If yes, does it happen with older Chrome versions on those platforms?
• OS specifics - Does it happen with older Android version (same or older Chrome version)? Does it only happen with the onscreen keyboard being shown? (I remember some issue on Android with keyboard overlay in the past...)
• Device specifics - Could be a single faulty device (maybe test on a different one), or OS-device specifics on a certain device class (maybe test with different vendor with similar OS specs). Imho graphics driver issues can be ruled out at this point, as the faulty behavior is not typical for GPU issues, also your usb notion indicates that.

Ofc there is still a chance, that the faulty behavior might result from xterm.js specifics - not on renderer level, but from the higher DOM screen layout and how xterm.js tries to deal with key and IME/emoji input. This is indeed somewhat hacky - it still relies on older, partially deprecated key event types, and the textarea layering is prolly the most cumbersome hack in xterm.js. But thats battle-tested and evolved over the years to its current state to support most browser engines/versions. There is always a chance, that a new browser version + OS specifics might break with some of the semantics used here (still I would not expect the browser to wipe/forget half of the screen data from that).

Maybe this helps you to narrow down your issues further.

[donbowman]

we have updated the ng-terminal wrapper to use latest xterm.js. this has somewhat improved, but it has duplicate key events, we are debugging still.