live-share
live-share copied to clipboard
Why is LiveShare `*` activated?
Describe the bug
When you are *
activated, you compete with vscode for start up time and as a result, you hurt vscode's startup time in the process.
It's better to be reactive and only activate when the user interacts with your extension:
- via a command
- via a view being visible
- etc
To Reproduce Steps to reproduce the behavior:
- Go to vscode.dev
- install liveshare
- reload the window
- liveshare is activated
Expected behavior It shouldn't activate until needed.
Additional context
Activation events for your reference (even though I know you know where these are) https://code.visualstudio.com/api/references/activation-events
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
Still would love to know why. This can help us improve the activation events of vscode.
Hey @TylerLeonhardt, I started looking into this issue. We are open to exploring activating Live Share upon a different activation event. However, Live Share has some scenarios where we need to reload VS Code and automatically reconnect to a Live Share session. One example of these scenarios is when a user joins a session as an anonymous user and then signs in during the session. To do this, we reload VS Code and upon reload, automatically rejoin them to the session as a signed-in user. For this scenario, we need to immediately activate Live Share, even if the user takes no action. Is there a way we could change our activation event for the majority of use cases while still keeping this behavior?
Also, is this a problem for vscode.dev, VS Code, or both?
@alyssajotice correct me if I'm wrong but wouldn't the activation event that you already have listed called onFileSystem:vsls
trigger in the case you're talking about? When you reload that user will be attempting to open a vsls FileSystem
Also, is this a problem for vscode.dev, VS Code, or both?
Both. The Activation events work the same way in this case.
Thanks for the suggestion. Let me give it a try and I'll make sure it works.
The only necessity for Live Share activating on *
that I know of is to support receiving a Live Share invitation. Live Share needs to be activated to establish a connection to the service and listen for these invitations. Of course, we could put this functionality behind a setting so that users could opt-out of receiving invites if they don't want Live Share always running.
Of course, we could put this functionality behind a setting so that users could opt-out of receiving invites if they don't want Live Share always running.
This would be my preference. When I use live share, I always am chatting with someone on Teams/Slack first and then they give me the LiveShare link that I open. I don't think I've ever invited someone out of the blue using LiveShare's tree view.
With that said, activation events are static so you could use a separate extension that maybe has this "always on" functionality.
- Base live share extension that doesn't activate on
*
- "Always on" live share extension that activates on
*
(well actuallyonStartupFinished
not*
) and depends on the base live share extension to be activated
Any updates on this one?
@TylerLeonhardt: I was taking a look at this one. As a quick test I tried replacing "*" with:
activationEvents": [ "onFileSystemAccess:vsls", "onFileSystem:vsls", "onCommand:liveshare.*", "onView:liveshare.*" ],
I noticed that the live share icon does not show up in the Activity Bar or Status Bar though until it is activated by invoking a liveshare command from the command palette. Is there a way to get these to show up without activating? Then if the user clicks on the icon in the Activity Bar, or invokes the share command from the Status Bar button, we can activate via the events listed above?
Before Activation:
After Activation:
Linking to https://github.com/microsoft/vscode/issues/167874
Moved away from *
activation in the latest release: 1.0.5788. Replaced with onStartupFinished
Resolving this one as we are no longer * activated. We can track further optimizations with #167874