Do not activate extension with workspaceContains always after installing

[DanTup]

I had a report of strange behaviour when installed the Flutter extension - it prompts you to install a Dart SDK (when you probably want to use Flutter, not Dart). It seems like installing the Flutter extension is activating the Dart extension (it does depend on it) even though no activation requirements for either extension are met, and the reason in the log is incorrect ("workspaceContains:**/pubspec.yaml").

Here's what I did:

• Open VS Code - ensure there is no open workspace/folder
• Install the Flutter extension (which will install the Dart extension)
• Note the Dart extension is activated, and the extension host log lists:

[2019-06-11 17:54:40.902] [exthost] [info] eager extensions activated
[2019-06-11 17:54:53.239] [exthost] [info] ExtensionService#_doActivateExtension Dart-Code.dart-code {"startup":false,"activationEvent":"workspaceContains:**/pubspec.yaml"}
[2019-06-11 17:54:53.240] [exthost] [info] ExtensionService#loadCommonJSModule /Users/dantup/.vscode/extensions/dart-code.dart-code-3.1.0/out/src/extension

Here's a screenshot showing I don't have a folder open with a pubspec.yaml in it:

Is this expected? Can I stop it?

[DanTup]

Actually, just installed Dart directly shows the same thing. What's strange is that installing the Flutter one does not activate the Flutter extension, so it's not like it's just activating whatever I install immediately 🤔

[DanTup]

Hmmm, I think it's because of this:

vscode/src/vs/workbench/services/extensions/electron-browser/extensionService.ts

Lines 306 to 307 in 022835e

	if (/^workspaceContains/.test(activationEvent)) {
	// do not trigger a search, just activate in this case...

😕

[DanTup]

FWIW the code above was added in 7304f38 (it's in a different file, as it was moved around a bit). I can't see a PR so not sure whether this was to fix an issue or something (cc @alexandrudima), but it's a bit undesirable for extensions that want to prompt the user to install an SDK based on the type of the open project. Currently we have no way to tell if VS Code activated this extension pre-emptively, or if the activation events were actually matched (so we can't even skip the prompt without re-checking for all the conditions ourselves).

[sandy081]

It was intentional to always activate any extension that has workspace contains activation event after installing due to the performance reasons.

I would wait for @alexandrudima 's opinion on this.

[DanTup]

I suspected it was performance related, but I think it's a false economy because:

1. You're now causing extension code to run that might not be needed, which can eat resources
2. The extension has to choose between:
   a) starting a language server that might not be needed (eats more resources)
   b) scanning the workspace itself to see if it's needed - thus undoing the savings VS Code made by not doing it

You're doing that work on a folder open anyway, I don't see why doing it at extension install is a huge deal (you probably already have some of the tree cached in the rendering for the explorer tree at this time too).

Also - if it's not considered a bug that extensions can activate when their conditions are not met, I think it should be called out explicitly in the docs (so it's clear they should decide whether or not they really should start up language servers, show user prompts, etc.).

[alexdima]

An extension can be activated outside the activationEvents. For example, another extension can be written which uses vscode.extensions API and activates any other extension programatically. Or another extension can be written which depends on the extension and its activation would lead to the activation of the original extension. So an extension should be prepared to be activated even outside the events listed in activationEvents...

That being said, the majority of extensions are not insanely expensive to activate... The entire idea of activation events is to reduce the impact extensions have on startup and to be economical, of course. But imagine the following scenario: the editorconfig extension activates on workspaceContains:**/.editorconfig and then you open a folder with hundreds of thousands of files... So many files that it would take entire minutes to go through them...

The editorconfig extension works by looking at the current opened text buffer and going up the folder hierarchy looking for .editorconfig... So once it is activated (which is cheap), its operation is also kind of cheap... For such an extension, it is much better to simply activate it if the search yields nothing after a certain amount of time. In such a case waiting for minutes to finish the search would be far more wasteful than simply giving up and activating the extension...

So IMHO it is not such a clear lack of judgement on our side to give up after some time and defer the decision of doing something to the extension. The extension has domain knowledge that we lack, an extension can implement something smarter than we can. The extension can also start searching and realising after a while that it is on a huge folder, but then it can present a popup which is specific to the extension, it can ask the user to define what exact behaviour they want...

For us, in the core, the decision is:

• keep going with searching (which might be unbounded on some crazy network shares, might consume minutes of 100% i/o on some poor disk, etc.)
• stop after a while and not activate the extension
• (current behaviour) stop after a while and activate the extension

I still believe we are doing the best given the limited information we have... The only thing which is debatable is for how long should we search until we give up. I think we just chose a number which seems reasonable...

[DanTup]

I still believe we are doing the best given the limited information we have...

Extensions have even more limited info though - we don't even get given the activation reason (I did ask). In fact, I recently opened a Dart project and the C# extension started downloading all sorts of .NET dependencies to my machine. The C# extension activates on tons of events (for ex. onDebugInitialConfigurations) and then just downloads all its dependencies regardless of what you have open. So the faster startup isn't really faster if extensions are doing lots of expensive work themselves.

The only thing which is debatable is for how long should we search until we give up. I think we just chose a number which seems reasonable...

There is no search. Check the code that I included above:

vscode/src/vs/workbench/services/extensions/electron-browser/extensionService.ts

Lines 306 to 307 in 022835e

	if (/^workspaceContains/.test(activationEvent)) {
	// do not trigger a search, just activate in this case...

When you install an extension, it just pre-emptively activates it if it has an onWorkspaceContains :(

[DanTup]

I just saw this again. I opened VS Code and it auto-updated the C# extension (I had a Dart project open). Because of this behaviour, the C# extension was unnecessarily activated. It then started downloading dependencies:

This logic doesn't seem to hold up. You're avoiding doing expensive things at startup and causing extensions to not only do expensive things, but illogical things. Fast forward a few years where I have 20 extensions that work like the C# one, and I've potentially got 20 extensions downloading SDKs when I opened VS Code with none of their projects open.

Is this really working as intended?

[alexdima]

To verify: Have an extension that uses workspaceContains. Then disable it and reload. If you enable it, the extension will only be activated if there is a real match. Before, it used to always be activated.

[alexdima]

@DanTup If you have a chance, could you please verify this?

[DanTup]

@alexdima sorry for the delay! I tested this in latest insiders, and it works great! With a non-Dart project open, if I install Dart/Flutter extensions, there is no activation. If I repeat with a Dart/Flutter extension open, they activate.

Thanks!

[alexdima]

Thank you! ❤️