So it seems the multiline paste issue (#311) was caused by how we multiplexed the WebSocket connections.
Since the WebShell is multiplexed over all the WebSocket connections, we can't have the terminal (xterm.js) reset the shell when it connects to the shell. This could cause someone in another instance of the terminal to lose state.
But that does mean that sometimes (likely a jline bug), jline doesn't send a newly connected terminal the fact that xterm's bracketed paste mode is enabled. This usually happens when the shell is reset (like when a newline or clear commands are given). When this happens xterm.js thinks that bracketed paste mode is disabled and trying to send the entire string as is without the bracketed paste mode delimiters.
To fix this, we manually send the code for enabling bracketed paste mode when a new WebSocket connects. Since enabling the mode is idempotent this doesn't affect the other terminals.
So it seems the multiline paste issue (#311) was caused by how we multiplexed the WebSocket connections.
Since the WebShell is multiplexed over all the WebSocket connections, we can't have the terminal (
xterm.js) reset the shell when it connects to the shell. This could cause someone in another instance of the terminal to lose state.But that does mean that sometimes (likely a
jlinebug),jlinedoesn't send a newly connected terminal the fact that xterm's bracketed paste mode is enabled. This usually happens when the shell is reset (like when a newline or clear commands are given). When this happensxterm.jsthinks that bracketed paste mode is disabled and trying to send the entire string as is without the bracketed paste mode delimiters.To fix this, we manually send the code for enabling bracketed paste mode when a new WebSocket connects. Since enabling the mode is idempotent this doesn't affect the other terminals.