How to avoid control characters when replaying history in xterm.js terminal #4869
-
|
Hi, I am handling a use case where I need to allow user to reload/recreate a previously loaded xterm.js window. This use case has a server component that stores all the data that was written to current session's Terminal instance. When a user reconnects to the same session again (perhaps using a different tab / browser), a new Terminal gets created and the server starts streaming (over a websocket) stored data to the new terminal instance. This approach seemed to work fine but after trying multiple reloads like that, I can see some control characters that are being rendered on the Terminal. I have shown a sample below - :0+r436f^[^[P0+r6b75^[^[P0+r6b64^[^[P0+r6b72^[^[P0+r6b6c^[^[P0+r2332^ After I press enter , I see the following sequence - 2R0;276;0c I have no idea about terminal sequences to be able to debug this issue. Any insights are highly appreciated. I am using an old version of xterm.js (3.0.0) because I am working on a legacy code. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
That 3.0.0 is really outdated. You should consider upgrading, around v4 we integrated a serialize addon, that can give you a replay of the buffer state w'o these sort of problems. As for v3 we cannot help you with that. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your comment @jerch . I will port the existing code to latest v4 (4.19.0) and retry the same scenario. As recommended by you, I will try to utilise SerializeAddon for storing the terminal buffer and use the buffer for reloading/recreating a new Terminal. The buffer shown in my original message seems to be coming from a vi editor session. And perhaps because there is no handler for it when terminal buffer is being replayed, these raw unhanded characters are being shown on the terminal. |
Beta Was this translation helpful? Give feedback.
-
|
Could it be, that you replayed the content on a new terminal, which already was connected to a PTY? If so - dont do that, replay first, then set up the connection to the PTY. I still recommend to update xtermjs, but why 4.19? Thats also way outdated, current version is 5.3 (note that we dont do backports). |
Beta Was this translation helpful? Give feedback.
-
|
@jerch I think your suspicion might be correct. I think Terminal is sending out some data while I am replaying historical buffer to it. I can solve this issue on the application side. I will also try to move to 5.3.0 but worried about any regression because of change in the APIs/Addon interfaces. |
Beta Was this translation helpful? Give feedback.
Could it be, that you replayed the content on a new terminal, which already was connected to a PTY? If so - dont do that, replay first, then set up the connection to the PTY.
Reason - a complex app like vi would always request some sort of reports, and those requests are contained in the data blob. The terminal will answer that with
onDataevents, which normally get forwarded to the PTY. Not in the replay case - the original response got already handled and is reflected in the followup data. Thus resending the responses to the PTY would be wrong here.I still recommend to update xtermjs, but why 4.19? Thats also way outdated, current version is 5.3 (note that we dont do backports).