Xterm.js: Support reverse-wraparound mode?

[backspace]

I’m implementing a highly-restricted terminal with Xterm.js to allow users to edit their desired remote execution command before they connect to a true terminal. The editable portion of the line is only at the end; the rest represents the full command that one would use to perform the same action in a non-web terminal.

It’s a bit hackish to be interpreting keyboard events to edit a string, but it’s been working well enough. However, I’ve now found that if the editable part of the command wraps to another line, backspacing doesn’t wrap to the previous line. I found this Super User answer that suggests I could use “reverse-wraparound mode” in a true xterm, but sending that to the Xterm.js terminal didn’t change the behaviour.

Reverse-wraparound mode is mentioned in some comments in Xterm.js’s input handler, but it seems like it’s not handled.

Is there any chance that this mode will be supported? If not I can surely detect whether backspacing has reached the beginning of the line and move to the previous one if necessary, but I thought I’d ask in case there’s hope that this will be added or if there’s something I’m missing, because handling it manually seems like it’ll add more brittleness. If there’s any desire for it to be incorporated into Xterm.js, I could try making a PR!

Thanks for all the work on this, it works perfectly once the remote session has begun, it’s impressively powerful 💞

[jerch]

@backspace Good you brought that one up, I'll look into it. Kinda would need it myself for my hackish fakepty implementation to get better ICANON support. But note that the support across other emulators is not that good (thus application code should not rely on it).

I’m implementing a highly-restricted terminal with Xterm.js to allow users to edit their desired remote execution command before they connect to a true terminal.

Speaking of restrictions - is that even possible solely done in xterm.js (thus on user side)? Imho you need a server component doing the command checks, otherwise a malicious user could just write to the pty stream directly.

[backspace]

Thanks for looking into it!

I don’t understand what you mean about possible malicious uses. The purpose of the restricted-editing is to set the command to whatever the user wants, which is then included in the URL for a WebSocket that connects to a shell started by that command. It’s a two-phase operation where first you specify the command and then use it to get a remote session.

[jerch]

@backspace Ah nvm - when I read "highly-restricted terminal with Xterm.js" I kinda thought you are trying to limit the command input for the user with xterm.js.

[jerch]

@backspace Can you check if #2724 works for you? Note that you have to switch reverse wrap-around on by sending CSI ? 45 h before you can use it. You can only revert soft wrap, hard line breaks by \n cannot be undone with it. Its also not possible to peek into the scrollbuffer (if the soft wrap happens from last line in scrollbuffer to the first in the viewport). Not sure yet if we should make that possible.

Just stumbled over your user name - full dedication or coincidence? (reverse wrap-around is implemented in the backspace handler) :smiley_cat:

[backspace]

The name really is an amazing coincidence from 2008, I love it having aligned with this so far in the future. Thanks for the possible fix, I should be able to try it out tomorrow! The limitations sound fine to me for my use case. 😍

[backspace]

I struggled a bit to get it built and importable in the application, but once I finally got that working, I can confirm that it does indeed behave as desired! This is great for me; I had written a workaround to handle something like this myself, but I definitely think it’s better to have included in Xterm.js, especially since it’s a real Xterm feature. Thank you so much! Let me know if there’s anything I can do to help get it merged.

[jerch]

Well I am unsure whether it should be able to fetch the last line from scrollbuffer back into the active cursor area. Downside of the current impl - if you have a rather longish command, that fills more than one terminal page, you cannot go all the way back to the first char of the command, it always stops at the top-left. Most likely not an issue for typical terminal sizes, still inconvenient. Like to hear your opinion in the regard.

Why I did not implement it in the first place - no other input/cursor action can peek into scrollbuffer so far (thus this would break with this terminal interface "rule"), furthermore its abit complicated to cover the edge cases with scroll margins correctly (we still have other issues with scroll margin :blush:).

[backspace]

Hmm yes, I see what you mean about the multi-page situation, I just tried it out. For my use case, I feel like this will never happen; even wrapping across one line should be rare, only when the pre-inserted and uneditable portion of the command happens to extend almost to the end of a line. But for a general solution, this limitation does seem worrying to me. I feel like reverse-wraparound will be rarely used in most cases, so maybe documenting this known limitation would be okay?

[jerch]

Thx for your feedback. Yeah gonna keep it that way for now and see if ppl have issues with it (unlikely, most ppl wont even be aware of that feature, other never input commands that long). The upcoming VT feature list will contain a note about reverse wrap-around once we merged it.