Filepath not converted in VSCode LiveShare guest

[Eskibear]

Live Share in VSCode enables collaborative editing among participants. I've tried it with Spring Boot projects, it's good that CodeLens and other live info are synced to guests, but some functionality is broken because the filepath is not converted.

E.g. In the following screenshot, it's a guest session on a Mac, and the host is on a Windows. By clicking <-OwnerRepository in the box, I'm supposed to open OwnerRepository.java in the virtualized file system. But the URL is the abosolute path of the host, which is directly synced to guest without conversion, which breaks the operation.

Unable to open 'OwnerRepository.java': File not found (file:///c:/Users/yanzh/Work/spring-petclinic/src/main/java/org/springframework/samples/petclinic/owner/OwnerRepository.java).

I find uri conversion APIs have been provided by package vsls, and the popular gitlens extension has already supported similar things with the piece of code. Is there any chance fix this broken use case for collaborative sessions? What I imagine now is, when Spring extension is also installed in the guest, it can do the correct conversion.

[martinlippert]

@Eskibear Please accept my apologizes for not coming back to this one earlier. This one somehow slipped through my bug triage and got lost. Sorry again for that.

Is this still an issue?

[Eskibear]

It's about Live Share experience, where multiple users can collaborate in the same workspace, editing, debugging, etc... I remember this was an edge case I found when I was playing Spring Boot projects with Live Share. I just tried it again and I can still repro it now.

Here is a basic scenario that users collaborate with project spring-petclinic (Host) Windows: host a collaboration session (Guest) macOS: join the collaboration session

On Windows, do following steps:

• Debug spring-petclinic with JMX enabled.
• Connect to corresponding process via "Manage Live Spring Boot Process Connections", and then live info shows.

On Mac:

• Debug session is synced automatically.
• You automatically see live info (codelens, hovering info, etc...) automatically, same as shown in Windows, transported by Live Share extension.

The problem is, the file urls are not translated (absolute path in Windows format). So the guest user cannot open it correctly.

After clicking, an error occurs because of the wrong URL.

If you have time, it would be better to cover this scenario to improve exprience for this group of users. Git-lens extension has already implemented this feature as I metioned above, and I guess it won't be too difficult. But after all, I don't know how many people are actually using this feature, blocked by this bug.

[BoykoAlex]

Even after looking at what gitlens has done I'm still not clear how to solve it... As far as I understand the link URI in the "guest" extension instance should be vsls protocol then there is hope it'd work i suppose... @Eskibear what is the "guest" extension instance... how does it work? I noticed that macos machine in the use case above doesn't have spring-boot extension present and there no LS started either obviously... All seems to be happening on the Win machine VSCode - there is spring-boot extension and LS running serving the "Host" extension instance... but where is the "Guest" extension instance? Does it run an LS process and talk to it? How does the "Guest" extension ghet its hover content? After looking at this VSCode Live Share stuff yesterday I'm can't stop questioning myself why we're trying to address links in hovers at the spring-boot extension level rather than at vsls extension level? Every extension creating links to local resources in hovers would face exactly the same issue and solve it in the same way... Feels like this should be addressed by vsls extension. Or am I missing something?

[Eskibear]

I'm not a LiveShare expert, and it was years ago. As far as I know, at that time LiveShare can fetch all "host" related items (codelens, hovering, ..etc) from vscode and sync them to "guest". So in "guest" machine, LiveShare extension is required, but spring-boot extension is optional.

why we're trying to address links in hovers at the spring-boot extension level rather than at vsls extension level?

I guess it's because LiveShare extension doesn't know which content should be converted and which should not. LiveShare extension lacks per-extension context information. E.g. if a link "command:myCmd" is synced to "guest", when you click it, myCmd should be executed on "guest" or "host"? (I don't know, seems there's related settings and mechanisms). I think that's why gitlens extension does some tricks, otherwise it doesn't have to do that.

As far as I understand, on "guest" machine, if only LiveShare extension is installed, then we cannot do anything to improve it, users see exactly the same content synced from "host". My original point is, if both LiveShare and Spring-boot extensions are installed, spring-boot extension might be able to do some tricks to convert the links, just like gitlens does, which would be a great improvement. But again I don't know how many people are actually using this feature.