JupyterHub Terminal gets clobbered with ascii color codes

[havarpan]

See this discussion in the jupyterhub forum. I (and my hub admins) would be pleased if we found out what causes this. Something more specific than "it's probably some xterm.js bug" or "it's probably caused by something happening on the server". The problem started to appear maybe three years ago (it didn't appear before that), and it seems to occur no matter what jupyterlab version we use or what underlying os we use (currently rocky 9). Here is the jupyterlab issue (linking to some xterm.js issues) that I found to be closest to our problem. But we get clobbered all the time, not just when reopening jupyterlab. Please help! :)

[jerch]

Interesting how people jump on the waggon "prolly an xterm.js fault".

Let me try to explain what you see there and why it is not an xterm.js but an integrator issue:

First what you see there is the output of a shell receiving terminal sequences it cannot process. So it mangles them and outputs them somehow. The question then is - why do sequences, that were not meant for a shell, end up there? Where do they come from?

Those sequences are either state reports or state requests the terminal does. It is important to know, that a terminal does never send those on own behalf, only on app or user's input (an explicit request). Thus the terminal was told by some input to ask for those sequences. Those state sequences are often used by alternate screen applications like vim etc. to do more advanced stuff on the terminal while termios ECHO and ICANON are off (so called raw mode, the app itself decides, what gets pushed to the terminal screen, if they would not disable ECHO & ICANON the screen would be flooded with the canonical repr of the line discipline for those sequences).

So we have rogue sequences from other applications at a shell. There is only one scenario I can think of, where this might happen - replay of terminal state from saved PTY streams feeding it back to the terminal, while the terminal is already attached to a PTY with a waiting shell at it.

The fix is rather simple - whenever terminal content gets replayed from a stored PTY data stream, do it on a terminal not attached to the active PTY. This is an integrator issue not pulling the PTY plug during terminal restores. Pulling it isn't harmful either, as the answer from a state request sequence is already in the data stream, because it got preserved within the data as well.

Hope this helps.

[havarpan]

Okay great! This is the kind of an explanation I have been looking for -- thanks!

I'm assuming that the meaning of 'integrator' is as in 'integrated terminal'. So this is a jupyterlab issue (occurring in all its environments) that doesn't have anything to do with xterm.js. Good to know. Will link this answer to the other discussions. Thanks again!

[jerch]

Yes integrator here means - whoever took xterm.js and populates it with replay data.