Terminal Cursor Position Reported Multiple Times

[adamsmd]

Describe what happened:

This is an issue relating to ANSI terminal escape codes.

When sharing a terminal with multiple users, issuing a DSR (Device Status Report) ANSI terminal code results in multiple CPR (Active Position Report) codes being returned, when only one should be returned.

Background

DSR is a terminal code that a terminal program can send to the terminal to ask the position of the cursor. CPR is a terminal code by which the terminal tells a terminal program the position of the cursor.

In my case, these are used when creating a dynamically-adjusting shell prompt. More generally these might be used by any program with a "curses"-like interface.

What was your system configuration? Product and Version [VS/VSCode]: VSCode OS Version[macOS/Windows]: Ubuntu 19.10 Live Share Extension Version: 1.0.2000 Target Platform or Language [e.g. Node.js]: N/A

Steps to Reproduce / Scenario: The following steps assume that:

• you are running a "Bash" shell,
• the host is the one entering commands to the terminal,
• there is sufficient network latency between the host and the remote user.

1. Host a live share session with at least one other person
2. Run the "Live Share: Share Terminal" command and select the "Read/Write" option. (I don't know if this also happens with "Read-only".)
3. Turn off any prompt customizations by running PS1='$ ' in the terminal.
4. Run printf '\e[6n'; IFS=';' read -rsdR ROW COL in the terminal

The printf issues a DSR code, and the read reads the returned CPR, so this should result in nothing seen by the user.

However, when a terminal is shared with multiple users, there are two CPR returned. This results in something like ;1R or 1R (which is the end of the second CPR) being put on the prompt.

I believe one of the CPRs is coming from the host's terminal and one is coming from the remote user's terminal. Thus, this bug might depend on how long it takes for the remote user's terminal to respond. Thus, it may require some latency in the network connection between the host and the remote user. I haven't measured exactly how much latency is needed, but from what I've seen 250ms should be more than enough.

The fix for this probably involves something that ensures that only the CPR that comes from the host's terminal is returned. This may need to also apply to other escape codes that terminals send back.

[jramsay]

@adamsmd: thanks for taking the time to report this issue!

Adding @IlyaBiryukov for investigation.

[IlyaBiryukov]

Thanks for reporting this issue and your thorough analysis! Indeed, we do not filter out ESC-sequences that we broadcast to session participants, and their terminal clients can respond to them, resulting in multiple responses coming back to the host terminal.

To set up the expectations, we may only get to fixing this issue in a month or later.

[derekbekoe]

We’re not able to prioritize this issue over the other higher-impact issues we receive every week, based on the votes and comments from others in the community and our understanding of the issue. We understand this may be disappointing; we've all been there, whether in this project or others we've contributed to. However, rest assured that we love your input. If you feel it deserves to stay open, then clarify your use case and contact us to let us know how severe it’s for you.