Extension activated despite capabilities flag when virtualWorkspaces is defined as false

[alefragnani]

I'm updating an extension to not support virtual workspaces, but it seems the Debug Session does not respect that capabilities flag.

I mean, I added "virtualWorkspaces": false to the capabilities property in package.json, but whenever I run a debug session and connect to some Virtual workspace, the extension remains enabled.

The only way I could test my extension was packaging and installing the .vsix.

Is debugging really not supported, or should I open an issue for you to take a look?

Thank you

Originally posted by @alefragnani in #123115 (comment)

[isidorn]

@aeschli also assigning to you for the virtualWorkspace capability.
Debug is not doing anything special here. Should we? Is there something we need to adopt?

[aeschli]

When a window contains a virtual workspace, all extensions that have _isDisabledByVirtualWorkspace should be disabled.
The launch and debug commands are also disabled.

@alefragnani Can you explain more, What is your extension contributing? What are the steps to reproduce the issue.

[alefragnani]

Hi @aeschli ,

You can easily reproduce the issue creating a new extension using the yeoman generator (yo code) and adding the capabilities entry.

1. Create a new extension using yo code
2. Open the extension in VS Code
3. Change activationEvents to * just to be activated automatically at start
4. Start debugging
5. Open any virtual workspace
6. You will see the extension being activated (which is ok)
7. Stop debugging
8. Add the capabilities entry in package.json, to not support virtual workspaces:

    "capabilities": {
        "virtualWorkspaces": false
    },

8. Start debugging
9. You will notice the extension is still being activated, but it shouldn't, because the workspace is virtual?

I totally understand if you say the extension is being activated because I'm debugging it, but how can I know the capabilities entry is working?

Maybe in this case, and also for untrusted workspaces, the debugging session could show a warning message (just like the one displayed when the debug fails with a time out), telling the developer that the extension is not being activated because it does not support virtual / untrusted workspaces.

the same issue happens with the untrustedWorkspaces entry.

BTW, I've noticed this issue while adding virtual/untrusted workspaces support to my Read-only Indicator extension.

Thank you

[aeschli]

I can reproduce. Thanks for the steps.
To open directly in a virtual workspace

• create a local workspace file: (test.code-workspace)

{
	"folders": [
		{
			"uri": "vscode-vfs://github/aeschli/schemas"
		}
	]
}

• add the path to the launch config:

...
			"args": [
				"--extensionDevelopmentPath=${workspaceFolder}",
				"C:\\Users\\martinae\\github-repo.code-workspace"
			],

Looks like the enablement state is not preventing the extension from being activated.
Also, the hello world command is in the command palette.

[aeschli]

Ah, we do this on purpose. The extension under development is never disabled:
https://github.com/microsoft/vscode/blob/main/src/vs/workbench/services/extensions/common/abstractExtensionService.ts#L694

[alefragnani]

Yeah, just like I was thinking 😬

So, is it something that could be changed on this, in order to properly test/validate if the capabilities flag is being respected? Maybe the warning message I commented above. Or should I simply ignore the fact that it was activated on debugging, and don't worry about it?

Thank you

[alexdima]

@sandy081 The current behavior was originally introduced by you in ce01a62 so I would leave it to you.

I would argue that the current behavior is OK, but maybe only extensions disabled via user action should be forcefully enabled, while extensions disabled due to capabilities should be left disabled. To implement this, more information is needed from the IWorkbenchExtensionEnablementService.

[sandy081]

I think current behaviour is OK to run the extension always. I also think giving more priority to capabilities also makes sense. But I am not sure the requested use case - in order to properly test/validate if the capabilities flag is being respected is good enough. Because this is a VS Code feature that is implemented/tested by VS Code and may not be a use case for extension.

[vscodenpa]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!