Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
donbowman opened this issue Nov 30, 2022 · 10 comments
Open

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

donbowman opened this issue Nov 30, 2022 · 10 comments

Comments

@donbowman
Copy link

donbowman commented Nov 30, 2022

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).
good

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

@Tyriar
Copy link
Member

Tyriar commented Nov 30, 2022

Are you using the builtin DOM renderer or an addon? This could be #4271

@donbowman
Copy link
Author

no addons. will examine that linked issue

@Tyriar
Copy link
Member

Tyriar commented Nov 30, 2022

xterm.js version: latest

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

@donbowman
Copy link
Author

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
Copy link
Member

Tyriar commented Nov 30, 2022

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
Copy link
Member

jerch commented Nov 30, 2022

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
Copy link
Author

donbowman commented Nov 30, 2022

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
Copy link
Author

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

@jerch
Copy link
Member

jerch commented Dec 1, 2022

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants