Extension viewlet does not reflect runtime state of extensions

[weinand]

testing #11023:

• VSCode Version: Version 1.5.0-insider
• OS Version: macOS
• launch VS Code from command line with --disable-extensions
  Observe: extension viewlet still shows all extension with an uninstall button. There is no indication that extensions are not active.

[joaomoreno]

Yeah, the extensions runtime state isn't connected to their management state.

This is both debt and feature work.

[hashhar]

@joaomoreno And while you people are at it, is there some way you could add support for deactivating extensions on the fly. Is it as simple as calling extension.deactivate() and extension.activate()?

[joaomoreno]

@hashhar ping @alexandrudima

[alexdima]

@hashhar Great question! On a first look, yes, it should be as easy as that.

However, not all extensions do everything 100% correctly, e.g.:

• perhaps it registers a command and forgets to .dispose() the registration
• perhaps it registers a language support and forgets to .dispose()
• perhaps it registers a file watcher, a document change listener and forgets to .dispose()
• etc.

I don't think we should have a "deactivate" action in the UI until we are certain we have deactivated an extension. One way we could guarantee this is if we'd return a special instance of the vscode module for each extension that requires vscode. In this case, we could identify which extension calls which API methods, keep track of all of that, and in a swift way remove all the registrations on our side. That could guarantee deactivation from the API point of view.

Now, there is an even more nasty class of issues, ones which involve third party resources. Imagine an extension does any of the following:

• spawns a process
• opens a file
• listens on a port
• connects to a server
• (other OS resources)
• provisions a server in the cloud
• makes an ftp connection

And it forgets to clean up all of that. Some of those resources get cleaned up by node on shutdown (releases file handles, on Windows kills child processes, stops listening to ports), so to really be certain on our side an extension has deactivated we'd need to hack node's require to the point where we return special instances of fs, child_process, net, which can safely clean after an extension.

TL;DR: We can call deactivate(), but that does not mean the extension is in any way really deactivated.

[hashhar]

@alexandrudima Thanks for the insight. I guess this is the difference between seasoned developers and freshly out of school. 😛

It means that there needs to be a policy to ensure all these things don't happen before this work can be done.

[sandy081]

Now, we indicate an extension being running or not.

Closing this.