π Bug: Files get opened automatically even while not following a participant.
Describe what happened:
What was your system configuration? Product and Version [VS/VSCode]: VSCode OS Version[macOS/Windows]: macOS Live Share Extension Version: v1.0.2478 Target Platform or Language [e.g. Node.js]: Node.js
Steps to Reproduce / Scenario:
- Host a new Live session.
- Invite a participant to your session.
- Make sure the participant isn't following the host.
- Close all open files, open any file in the project and save it.
The file will open on participant's session when it shouldn't.
The behavior happens even with the following options:
"liveshare.shareExternalFiles": false,
"liveshare.focusBehavior": "prompt"
Thanks for reaching out. Can you give us more details about your scenario? is the file you open, a file in the same project or external file ?
Here's a screen recording demo @setaskin . It's files in the same project that another participant opens, regardless of the participant. It will just open to everyone connected.
Any thoughts? @setaskin
I can repro the issue @daytonellwanger can you take look ? feel free to reassign if it is not your area.
@fubaduba @daytonellwanger - Any thoughts? It's the only major obstacle when working with multiple developers live.
@altechzilla I'm able to repro, so should be easy to figure out and fix. Just need to get that work scheduled.. I'll keep you posted with updates.
Thanks a lot @daytonellwanger - it would improve my teamβs productivity by orders of magnitude.
Any updates @daytonellwanger ?
Hey @altechzilla , we still haven't scheduled this work. @fubaduba , do you think this fits into our plans for this sprint or next?
π We use Live Share daily and it's really confusing when they keep popping up for everyone. Thank you for the follow-up!
Any updates @daytonellwanger @fubaduba? Thanks!
I've got this one on our radar @altechzilla . Hope to have a response for you soon.
Thank you @Davsterl !
@altechzilla, I'm looking into this now. Thanks for your patience!
@altechzilla, I'm looking into this now. Thanks for your patience!
Great! It's been a big hiccup so I'd really appreciate a patch for it. Thank you!
Hey @altechzilla, I am trying to get a better understanding of this issue. We can divide the scenario into two parts:
-
When a host opens a file and makes an edit, it opens the file on all of the guest machines as an additional editor tab.
-
When a guest opens a file and makes an edit, it opens the file on all of the other machines (including the host) as an additional editor tab.
We are not currently able to fix part 2 due to VS Code limitations. I am opening an issue with them to start the conversation about that. We do have the ability to fix part 1 on our end. Before doing that, can you explain which of these scenarios are causing the issue?
Also, can you describe how the additional files are affecting your use of Live Share? When I repro, the opened files do not affect the active editor, so it doesn't seem to interrupt my workflow. Do you often host Live Share sessions with a larger number of participants, causing a large number of files to be opened? Additional details about that would be helpful. Thanks!
Hey @alyssajotice ,
Yes, that's correct! But to clarify, it's only when you actually save a file, not when you open it by default. But in an environment where a lot of files are being constantly edited and saved, it quickly turns into a headache.
Both scenarios are equally problematic because they cause a lot of clutter in the tabs area.
We work with a few developers live on the same project. The only workaround I was able to figure out in the meantime was having each person pin their tabs, but pinning and unpinning tabs is not exactly a productive thing to do.
Devs often edit multiple files at the same time, not always by splitting their view. So having their tabs get added randomly to their bar is quite disruptive.
I hope that makes sense, but let me know if you need any more clarification.
Thank you for looking into it!
Thanks for the additional info @altechzilla! I understand why it is a problem and we will likely pursue a change with VS Code to fix both parts of the scenario described above.
I would like to explore this description of the repro:
But to clarify, it's only when you actually save a file, not when you open it by default.
When I repro the scenario, the save action is not what opens the file. Rather, the edit action is what opens the file.
Here is my list of repro steps:
- Open two windows of VS Code
- Share a Live Share session from one window
- Join from the other
- Ensure neither participant is following the other
- Ensure auto-save is turned off in VS Code
- Have the guest open a file that is not currently open for the host
- Click in the file, add a character
The file will open as an additional tab in the host's editor.
I have added saving at various times in this list of steps but it does not change the behavior I've described above. For example, if I open a file, make no edits, and save, the issue doesn't repro.
Can you please try these steps and/or provide a new list of repro steps that are more specific and can be reproduced on one machine with two VS Code windows open?
@altechzilla I've found a workaround for this issue. You can turn on auto save for VS Code and make the delay less than 1s. This should be a patch for the issue. Let me know if this works and in the meantime, I will continue investigating.
Hey @altechzilla, I wanted to follow up on this! Did this workaround fix your issue?
Hey @alyssajotice ! That worked π Thank you! Is and official fix coming that doesn't require the workaround?
@alyssajotice - Files aren't opening anymore but because the autosave delay is so low, it causes errors when hot reloading for the other session participants. So we can't use the workaround unfortunately.
@altechzilla can you attach a photo of what kind of error you are getting?
@alyssajotice - While writing code (with autosave on), basically it keeps saving before you finish typing. Meaning that when the browser hot reloads, it will throw errors because of the unfinished code.
Like if you're typing function and only got to type func within the given delay, it will save the file, and when it hot refreshes the browser (for everyone in the Live session), it will break the page.
It's not really a good workaround, though it does prevent tabs from being open across users.
@altechzilla thanks for the info. For your typical Live Share scenario, how many users are using Live Share via the browser versus on VS Code? Is the reload issue only happening on browser?
This is unrelated to the number of users or the reload thing. The core issue is that there's a bug in live-share that causes tabs to open when they shouldn't. It would be great if someone in the core team could look into it and treat the cause instead of bandaiding the effects.
Hey @altechzilla, we appreciate your feedback on how the flow of unsaved files is disruptive for you and your team. Our team has discussed this in great depth. The workaround being provided was to ease some of the UX clutter you were feeling, however we do recommend Live Sharing without the auto-save on, for a more optimal experience. The opening of unsaved files on both host and guest sides are a design implementation that is critical to file operations in VS Code for Live Share. We have tried to minimize the distraction caused by this by ensuring that if you're not following your fellow participants opening an unsaved file, it doesn't yank you away from what you're currently doing. We will hold this feedback for the future, and get more validation for it before we implement a big design change to one of fundamental file operations. Thank you again for your feedback.
Hey @fubaduba ,
Thank you for the in-depth response, I really appreciate it.
I understand that it would require more validation - I would really hope the issue gets some attention and that it could become an opt-in setting under preferences rather than a default. π
Will work within the current limitations for now.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically in 2 days.
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βs for you.