live-share icon indicating copy to clipboard operation
live-share copied to clipboard

Share guest-created untitled documents

Open svdo opened this issue 5 years ago • 6 comments

Today we observed the following issue: while collaborating in a live share session, the guest creates a "new untitled file", which gets the name "Untitled-1". The guest puts some content in the file. The host does not see the file at this point. Now the host also creates a new file, which also gets the name "Untitled-1". The guest has now lost the contents of their "Untitled-1" file and sees the contents of the host's file instead.

What was your system configuration? Product and Version [VS/VSCode]: 1.50.1 OS Version[macOS/Windows]: macOS host, Windows guest Live Share Extension Version: 1.0.3071 Target Platform or Language [e.g. Node.js]: Clojure (but that is probably irrelevant to the issue)

Steps to Reproduce / Scenario:

  1. Host opens project
  2. Host starts live share
  3. Guest connects to host's project over live share
  4. Guest creates "new untitled file" using the corresponding VSCode command, file gets name "Untitled-1"
  5. Note that the file is not visible to the host at this point, which it would be if the host would have created the file. (That is probably already a bug.)
  6. Guest types some content in the file.
  7. Host creates "new untitled file" using the corresponding VSCode command, file gets name "Untitled-1"
  8. Guest's "Untitled-1" file is now the same one as the host's, which means that the content guest put in in step 6 is now lost.

svdo avatar Nov 03 '20 20:11 svdo

Great find @svdo ! And thanks very much for the detailed repro steps.

(5) is by design - the mental model to have is that Live Share shares the host's state with the guest, including untitled files. When the guest creates an untitled file, it exists outside of the Live Share session. It's just a local file. (Note that the guest can create shared files, but it's via the file operations in the file tree). But maybe we should rethink that design. When you create an untitled file on the guest, would you expect it to be shared with the host?

No matter the experience here, we certainly shouldn't overwrite the local contents of the guest's untitled file when the host creates an untitled file.

daytonellwanger avatar Nov 06 '20 16:11 daytonellwanger

Thanks @daytonellwanger! Regarding your question: indeed when I create a new file in a live share session window, personally I would expect it to be visible to all parties, regardless of who created the file. My mental model is that the window represents the share session.

svdo avatar Nov 06 '20 16:11 svdo

Thanks @svdo ! That's very useful to hear your perspective. Let me give this some thought and then see if we can get this on the backlog.

daytonellwanger avatar Nov 06 '20 20:11 daytonellwanger

Yeah I agree with @svdo’s suggestion here. When a guest creates a new untitled document, we should remote/synchronize that gesture to the host. Otherwise, it’s odd that host-created untitled documents are synced, but not guest-created.

I believe we originally restricted this behavior, because once the guest went to save the untitled document, we didn’t have UI to actually select the save location. However, now that VS Code remote introduced a remote file picker, we may be able to re-use that for this purpose.

lostintangent avatar Dec 22 '20 04:12 lostintangent

This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically in 2 days.

github-actions[bot] avatar Aug 15 '22 10:08 github-actions[bot]

@daytonellwanger Did you have any additional thoughts about this since last time? I think it would still be nice to address this (especially since it can result in loss of content on the guest's side), but of course I also understand the need to prioritize things.

svdo avatar Aug 15 '22 10:08 svdo

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. 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 is for you.

derekbekoe avatar Mar 29 '23 00:03 derekbekoe

I understand that difficult decisions need to be made. And in fact I feel it's probably better to be clear about this than having it unclear like it was before. Having said that, I'm super disappointed. For my team this behaviour is the only single thing that should change about live share, and then it's done, gift wrap it, don't change it anymore. It means that, when we're remote pair programming (which is what we use Live Share for), basically only one person is allowed to touch the keys. Others cannot even do so much as a spelling fix, because it will mess up undo-redo for everybody. It's similar to the backspace-key: advanced typists don't consciously press the button, their brain subconsciously registers that a wrong key was pressed, and automatically the backspace and the right key get pressed. With undo/redo it's the same. You make a mistake, hit undo, fix it. You don't even have to check the result, because you know what happens when you do these actions. You do them all the time when you're working "solo". But now you're working in Live Share and the whole thing changes. You can no longer trust that the right thing happens when you hit "undo" or "redo". You have to verify it every single time. And then, when it didn't do what you expected because somebody else fixed a typo or something, there is a hard stop. Everybody stop what they are doing, remember what they just did, hit undo to a point where you are seeing the expected things again, and then cautiously do the changes you wanted to do again.

It breaks you out of flow.

I don't know if there are better alternatives than Live Share (for example, using IntellIJ and "Code with Me"), but this decision means to me that I'll have to bite the bullet and find out. Please don't take this as complaining or something, I'm just clarifying why I (and my team) feel the prioritisation of this issue is incorrect.

With that, I sincerely thank you for all the time and energy you're putting in this otherwise great extension!

svdo avatar Mar 29 '23 07:03 svdo