-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
Are you using the builtin DOM renderer or an addon? This could be #4271 |
no addons. will examine that linked issue |
No addons and this is on v5? If so I'm not sure what could be the issue here. |
in our code base we are using NgTerminal, which in turn calls xterm 4.19.0. In the other xtermjs using sw i tried (https://github.com/tsl0922/ttyd), it uses:
with I also tried github.com/elisescu/tty-share which uses it does not appear to have any addons or set render type. |
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? |
Since it seems to fail with all renderer versions and different xterm.js versions - maybe this is the culprit: "Chrome 108 (chrome beta)"? Edit: |
So this is indeed on chrome beta... but it will be chrome stable soon enough :) 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). |
ps, chrome 108 is no longer beta |
And the issues are not gone I guess? My reasoning why I think the root cause may not be in xterm.js itself:
Some outer possibilities, that would need further narrowing:
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. |
we have updated the ng-terminal wrapper to use latest xterm.js. |
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
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.
The text was updated successfully, but these errors were encountered: