Add the ability to pass "post extension install" query parameters

[legomushroom]

To smoothen onboarding experience VSCode extensions users have, we need the ability to pass a query parameter to the protocol handler, and after successful installation, the parameter(s) be passed to the activate function as part of extension context or as a separate argument. This allows extensions to implement the one-click-to-acquisition-and-action experience during onboarding (in case of VS Live Share it will be one-click-install-and-join experience).

1. URI expample: vscode:extension/MS-vsliveshare.vsliveshare?workspaceId=7F32B1A89D3B88CB9DA59683E89206D810DA
2. After successfull instalaltion { workspaceId: "7F32B1A89D3B88CB9DA59683E89206D810DA" } can be passed to the activate function as part of the extensionContext or as separate parameter.
3. Extension reads the params and knows to take the appropriate action.

Ideally, the marketplace will be able to pipe the query parameters too (e.g. https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare&installationParam=7F32B1A89D3B88CB9DA59683E89206D810DA).

Thanks!

[joaomoreno]

Discussed this with @sandy081 and we came up with a separate solution other than piggybacking on the installation URIs.

Extensions now have access to API to register Uri handlers. This let's an installed extension directly handle system-wide Uris. Currently, if the user opens a Uri intended to be handled by an extension which isn't installed, nothing happens. We could instead piggyback on this API and suggest to the user whether he'd like to install that extension. If confirmed, we then suggest to the user to reload the window. If confirmed, the extension will be automatically activated and the Uri will be provided to it via the API hook.

marketplace will be able to pipe the query parameters too

If this isn't a requirement, we suggest to follow our solution. Would it work for you guys?

[grork]

Would the marketplace automatically grovel packages for URI handlers, and automatically suggest them based on that? or would there be some other mechanism for registering these manually? (e.g. in the marketplace registration page?)

[legomushroom]

@joaomoreno the suggested approach sounds great for us, one pitfall:

We have our own URI handler implementation and having this new capability only in the latest versions VSCode means that we cannot fully switch to it (we support latest 6 versions now). We have to either wait until appropriate stable version margin gained or to have some kind of fallback to our old approach. Detection of a system-registered URI handler from a web page is challenging and error-prone hence unreliable (only FireFox has more or less reliable detection means), do you have any ideas how VSCode can help us to detect the handler?

[joaomoreno]

Would the marketplace automatically grovel packages for URI handlers, and automatically suggest them based on that? or would there be some other mechanism for registering these manually? (e.g. in the marketplace registration page?)

No, the Marketplace would require no changes. You would be the owners of whatever page which shows the extension URI. The Marketplace also doesn't know about the semantics of each extension URI. As far as I understood, you'd like URIs that immediately start a specific session... why would the users go through the Marketplace when clicking them?

Detection of a system-registered URI handler from a web page is challenging and error-prone hence unreliable (only FireFox has more or less reliable detection means), do you have any ideas how VSCode can help us to detect the handler?

Detection simply doesn't work. Why would you want to detect it? You can also provide the link as well as directions of what to do if the link doesn't work.

We have our own URI handler implementation and having this new capability only in the latest versions VSCode means that we cannot fully switch to it (we support latest 6 versions now).

I don't think that this would be a breaking change for your existing users in older versions. Can you elaborate on why that would be the case?

[legomushroom]

@joaomoreno

The main issue is that the new capabilities suggested here will only be available at the latest versions of VSCode and, right now, we support up to the 6 latest VSCode versions with our extension. This means that if we just switch to the new approach we leave the majority of our user base behind hence we want to be able to fall back to our existing protocol handler approach in case if a user has of the older VSCode.

The problem is amplified for us since:

• If a user with older VSCode version triggers the handler, they eventually will be left in some confused state as VSCode will be opened but nothing will happen afterward.
• We cannot detect if the new approach is present nor we can't trigger two handlers(vscode one and ours) at the same time since it will open VSCode twice.

I guess the right solution for us is to wait until the feature propagates to a larger chunk of our user base and entirely switch to the new approach at once.

Hope it makes sense.

[joaomoreno]

I guess the right solution for us is to wait until the feature propagates to a larger chunk of our user base and entirely switch to the new approach at once.

It really is... Unless you want to have two clickable buttons targeting the two Code version ranges. But won't you have this issue regardless of the solution? If it's an improvement on Code's URI handling feature, you're bound to the version of Code which supports that.

We do our best to push updates to our users, but some will always lag behind, sure. Still, here are some adoption stats from today:

• >= 1.27 38%
• >= 1.26 70%
• >= 1.25 82%
• >= 1.24 86%

[legomushroom]

@joaomoreno great, thanks for the stats insight. Please, let us know when the feature is available in the insiders so we can test it early. Thanks for your help!

[sandy081]

Implemented and should be available in tomorrow's insiders.