Live Share link is opening VS Code on the web instead of the desktop

[itsgeegeez]

Describe what happened:

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

Steps to Reproduce / Scenario:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Please attach logs to this issue: You can access them via the Live Share: Export Logs command from the command palette (ctrl + shift + p) and attach them to this issue

Screenshots If applicable, add screenshots to help explain your problem.

[Yuri-Santiago]

I have the same problem and I can't use the join manually.

[Francisco-Carvalho98]

having the same problem. is this from an update to the extension or is it server side?

[relandboyle]

@itsGeeGeez @Yuri-Santiago @Francisco-Carvalho98 Did you post/comment on this issue immediately when you noticed a problem? Or were you able to ignore it or work around it for a few days before the issue got worse?

The current version is v1.0.5043. A good first step is to ensure you are using the current version. I don't see a release date on this version in the changelog but we started having issues approximately one week ago.

Clicking a team member's Live Share link now opens the browser editor, which is highly undesirable behavior. We never, ever want to see that. It's not clear if there is still any way to use Live Share within the VS Code application in Windows, which is concerning because we depend on it in some situations.

UI behavior is inconsistent. Clicking the "Join" button usually results in nothing happening / no feedback at all. Occasionally, often after a very long delay, the text input window will appear but Live Share will still fail to connect. In many cases there is no additional feedback and no error alert. Clicking the "Share" button results in starting a share session, sometimes immediately but usually after a delay of more than two minutes, but no one else can join the session so it's not useful at all.

[fubaduba]

I have the same problem and I can't use the join manually. @Yuri-Santiago What do you see when you try to join manually?

[fubaduba]

having the same problem. is this from an update to the extension or is it server side?

@Francisco-Carvalho98 are you still seeing this issue? Same question as above- what happens when you try to join manualy?

[fubaduba]

@GlorifiedBicycle Thank you for your feedback. The current behavior does default to the web editor, instead of the web-page re-direct that existed before. I would love to know more about why you find it undesirable. Did you generally use VS Code or Visual Studio as a guest, and do you find it hard to open the session in desktop now? I also see you've been facing some issues with the share and join buttons. Are you able to share the logs from any of these sessions?

[airtonix]

@GlorifiedBicycle Thank you for your feedback. The current behavior does default to the web editor, instead of the web-page re-direct that existed before. I would love to know more about why you find it undesirable. Did you generally use VS Code or Visual Studio as a guest, and do you find it hard to open the session in desktop now? I also see you've been facing some issues with the share and join buttons. Are you able to share the logs from any of these sessions?

why? because that's what we want. isn't that good enough?

[ghost]

this is stupid, I don't want to use the browser. vscode.dev has existed for so long and I hated it every since it was made.

[relandboyle]

@fubaduba Thank you for your response.

Logs attached. I'm not familiar with these logs but they appear to cover a recent 48-hour period. Is that helpful?

FYI there are a couple of MS people also engaging on https://github.com/MicrosoftDocs/live-share/issues/4469.

Off the top of my head, here are a few reasons why I consider it undesirable to have Live Share links open in the browser client.

I am a Win 10 user, and I do 95% of my work in Linux via WSL2. I don't think it will be practical to access projects in my Linux file system via the Chrome browser in Win 10. Am I right? I'm checking now, and I do not see an Install button on the store page for the Remote - WSL extension. If there are many extensions that I won't be able to install, or just one extension that I like or need and won't be able to install, that is a deal breaker.

I've spent a fair amount of effort getting my VS Code environment set up the way I like it and getting accustomed to certain workflows. While I'm sure I could get accustomed to splitting my time between the VS Code for Web and the Windows app, I am not seeing a reason to expend that effort. Immediately I see that my settings have not been synchronized, and I'm not inclined to wonder whether it's possible to sync. I just want to continue working the way I have been working.

The way I have my web browser set up, approximately 100 pixels at the top of the screen are occupied by the tabs, address bar, and bookmarks. It's roughly double the height taken by the menu bar and tabs in VS Code. 50 pixels may not seem like a lot but I think it's significant. I could always go full-screen, and then the difference is reduced a bit, but that's not what I do.

As I'm researching my response to you I am noticing this message when I try to open a terminal: "Terminals are not available in the web editor. To use the terminal, you will need to continue in an environment that can run code, like a codespace or local VS Code." Now I'm not really sure what this discussion is all about. If there's no terminal and I can't run code, then I'm not sure I understand the purpose of VS Code for Web. If it's just for showing code to people who have no local editor or development environment then I think screen sharing via Zoom or similar is much better suited to that application. This works well when presenting or collaborating. When I am not in a Live Share session with a fellow engineer I want to be able to share my editor, and my browser, and my calculator, and Postman, and anything else that occurs to me in the course of a session.

Filisha, I hope the above can be helpful.

For context, I am enrolled in a coding boot camp where everyone uses VS Code and Live Share to pair program. We are evenly split between Mac OS and Win / WSL2 users. Perhaps when we're all a bit more experienced we will forget about Live Share and move on to other tools. For right now, the recent changes are quite inconvenient.

Thank you.

logs.zip

[airtonix]

@GlorifiedBicycle

I've spent a fair amount of effort getting my VS Code environment set up the way I like it and getting accustomed to certain workflows. While I'm sure I could get accustomed to splitting my time between the VS Code for Web and the Windows app, I am not seeing a reason to expend that effort. Immediately I see that my settings have not been synchronized, and I'm not inclined to wonder whether it's possible to sync. I just want to continue working the way I have been working.

logs.zip

Even if you did connect to someone elses live share session in your vscode editor, you'd only keep your theme and icons. Correct my if I'm wrong but all your extensions are not brought along.

[relandboyle]

@airtonix That may be true (I'm not sure if there are some extensions that do work when you're a Live Share guest) but the icons and themes have some value.

The larger point is that I never want to be made to use a tool that I did not choose, and in particular I don't want to be made to use an additional tool when I already have a tool that I like.

I'm sure there is some reason why MS is developing VS Code for Web. It should be possible to do that without disrupting or degrading the experience of VS Code or Visual Studio users. The webpage that opens when a link is clicked can check to see if VS Code or Visual Studio are installed, or it can allow the user to select the desired behavior and save the selection.

I've already started test-driving other editors and other collaboration solutions, something that didn't really interest me before last week. Some of my classmates and I are toying with the idea of developing our own alternative to MS Live Share. I'll be as surprised as anyone if we actually follow through with that idea, but we could. And someone else might be similarly inspired. UX matters.

[ajlive]

@GlorifiedBicycle is right on all points.

I just want to continue working the way I have been working.

Why shouldn't we be able to? Rerouting to vscode.dev with no way to change that behavior is a big change, and saying, "what's wrong with vscode.dev," isn't addressing the point. That being said, there are plenty of things wrong with vscode.dev, including poor browser behavior, apparently being yet one more thing I have to set up and configure (that I shouldn't have to because I don't want to use it), and easily losing the tab/window containing the workspace.

My team has relied on live share for remote pairing. It's a work tool for us and this new behavior has annoyed and frustrated all of us. Why do we have to configure one more thing we don't want to use?

We're concerned that Live Share seems like it's being deprecated or converted into a one-off sharing feature or even just a marketing bullet point: "open in your browser, no install required."

[azusa]

Hi, I had a same problem when I use Live Share. I found a workaround that they pastes a link via Command Pallet or Live Share Side Bar. Then they can use Live Share with VSCode.

[lostintangent]

Hey all! We really apologize for the interruption in your workflow here 🙏 This change was made, in order to help users get into a collaboration session faster, since we were seeing a lot of struggles for folks, that maybe didn't have VS/VS Code installed, or had never used one of these tools before. And so in order to lower the barrier of entry, for use cases such as education, hackathons and technical interviews, we wanted to use the web client as our new "jumping off point", much like you'd see with other collaboration tools. That said, we clearly screwed this up 😞

Just to make sure folks are unblocked ASAP, we published some new docs on how to join a Live Share session from the browser. Please let us know if this works for you, in the meantime of us discussing a way to default to desktop.

Aside from that option, we're discussing making a change to the web flow, that will prompt the user for their client option, and then "persist" that selection in the future. That way, if you click on a Live Share link, and then select VS Code (for example), it will automatically launch VS Code on subsequent link clicks. But if you selected to continue in the web, then subsequent clicks would automatically join you from the browser. That way, it's optimized for user preference, and allows retaining the previous desktop behavior, while improving the web flow. What do folks think? Any thoughts on that, as we're finalizing the design? Thanks again for the feedback here, and stay tuned for updates!

[ajlive]

I would be happy with a dialog presented that asked me whether to open in vscode.dev or in the desktop app, with a checkbox or some other mechanism to remember my choice. Thanks!

[relandboyle]

@lostintangent @fubaduba

This is a great response. Thank you.

Aside from that option, we're discussing making a change to the web flow, that will prompt the user for their client option, and then "persist" that selection in the future.

To me, this seems like the only move.

If there's a way the browser can check to see if VS Code is installed or running, and only offer the option to open in VS Code if it is installed, that would prevent new/non-users from being asked to make a choice.

Even better would be if this setting could be managed via the extension UI within VS Code. This way, if you don't have VS Code installed then there is nothing to manage and no chance of being prompted to open in VS Code. Let the setting default to "open in browser, no prompt" and if the VS Code extension is installed, allow the option to change "open in VS Code, no prompt" or "always prompt".

Thank you very much.

[lostintangent]

Hey all! Just as an update here: we pushed a new version of Live Share, that implements the design I mentioned above. In particular, when someone clicks on a Live Share link, they'll now be prompted with the following dialog:

If you select Open in Visual Studio Code then it will launch VS Code, install Live Share (if necessary) and then join you into the session from the desktop. Additionally, this gesture will set the new Live Share: Launcher Client setting to visualStudioCode, so that on subsequent visits, Live Share will automatically launch VS Code for you. This way, it retains the same behavior of our old "join page". If this is the behavior you want, then you don't need to worry about managing this setting at all, it will "just work" for you.

If you select Continue in Web, then it will join the session from your browser. Additionally, selecting this will set the new Live Share: Launcher Client setting to web, so that on subsequent visits, Live Share will automatically join from the web. However, if you join a session from the web, and later decide that you want to join from the desktop, you can use any of the instructions here. That way, you can select a preferred editor, but transition to a different one later.

We wanted to get this update out ASAP, to allow existing users to continue using the workflow they previously had. Moving forward, we'll look into refining this further, taking some of the suggestions that @GlorifiedBicycle mentioned above.

Let us know how this new flow works and if you have any feedback. Thanks again for your patience here!

[lostintangent]

We've validated this flow with a handful of users, and so I'm going to close this issue for now as resolved. Please feel free to file new feedback issues, that we can used to track any additional changes/improvements to the join flow beyond what I mentioned above. Thanks again for all the great input here! 🚀

[StingyJack]

why you find it undesirable

@lostintangent - ...because the session that was started and shared with me is a Visual Studio session. Why should I expect to see the shortcut launch a web page version of vscode or a local vscode ?

allow existing users to continue using the workflow they previously had.

the last time I tried live share in visual studio (which was a while ago) I didnt have to do anything special to make the session start via Visual Studio.

[MelGrubb]

Is there any option, existing or planned, to allow me to click the share link and open full-blown Visual Studio? Not VS Code, and certainly not VS Code in a browser. I mean, that's fine for lowering the barrier to entry, or making it easy on hackathon crowds, but when I'm pairing with someone at work, I want to use my real tools by default. Did I accidentally click something once and lock myself out of the choice forever, or was there never a choice to use my full VS2022 installation?

[otri]

😡 This is still so stinking undiscoverable!!!!

[romaindurand]

I fixed it by setting the "liveshare.launcherClient" to "visualStudioCode" and resetting all the site permissions on Chrome. I also made sure to be connected (via github) in the browser so my settings would be loaded.