Extensions using htmlLanguageParticipants don't activate vscode.html-language-features

[devmattrick]

Does this issue occur when all extensions are disabled?: Yes (apart from the extension I'm testing)

• VS Code Version: 1.71.0 784b0177c56c607789f9638da7b6bf3230d47a8c x64
• OS Version: 5.19.7-arch1-1

Steps to Reproduce:

1. Create an extension using htmlLanguageParticipants (you can see the code I'm using at Enable VSCode HTML Lanaguage Participants samuelcolvin/jinjahtml-vscode#118)
2. Load that extension into a debug window
3. Open a language that has htmlLanguageParticipants enabled for it (I'm using jinja-html)
4. Notice that HTML language participant support is not working
5. Switch language mode to the html language provided by vscode.html-language-features, causing that extension to load
6. Switch back to a language using htmlLanguageParticipants
7. Notice that HTML language participant support is working now

It looks like the built in Handlebars extension may mitigate this by adding a language activation for handlebars to the package.json of the html-language-features extension but this seems hacky and probably not ideal for third party extensions.

Ext Host Logs:

On startup:

[2022-09-09 18:12:00.110] [exthost] [info] Extension host with pid 359485 started
[2022-09-09 18:12:00.110] [exthost] [info] Skipping acquiring lock for /home/matt/.config/Code/User/workspaceStorage/5f95745873455f863d9a75ba9df82c4a.
[2022-09-09 18:12:00.203] [exthost] [info] ExtensionService#_doActivateExtension vscode.microsoft-authentication, startup: false, activationEvent: 'onAuthenticationRequest:microsoft'
[2022-09-09 18:12:00.314] [exthost] [info] ExtensionService#_doActivateExtension vscode.debug-auto-launch, startup: true, activationEvent: '*'
[2022-09-09 18:12:00.318] [exthost] [info] ExtensionService#_doActivateExtension vscode.git-base, startup: true, activationEvent: '*', root cause: vscode.git
[2022-09-09 18:12:00.323] [exthost] [info] ExtensionService#_doActivateExtension vscode.ipynb, startup: true, activationEvent: '*'
[2022-09-09 18:12:00.351] [exthost] [info] ExtensionService#_doActivateExtension vscode.git, startup: true, activationEvent: '*'
[2022-09-09 18:12:00.497] [exthost] [info] ExtensionService#_doActivateExtension vscode.github, startup: true, activationEvent: '*'
[2022-09-09 18:12:00.550] [exthost] [info] Eager extensions activated
[2022-09-09 18:12:00.569] [exthost] [info] ExtensionService#_doActivateExtension vscode.emmet, startup: false, activationEvent: 'onStartupFinished'
[2022-09-09 18:12:00.611] [exthost] [info] ExtensionService#_doActivateExtension vscode.merge-conflict, startup: false, activationEvent: 'onStartupFinished'
[2022-09-09 18:12:00.659] [exthost] [info] ExtensionService#_doActivateExtension vscode.github-authentication, startup: false, activationEvent: 'onAuthenticationRequest:github'
[2022-09-09 18:12:00.747] [exthost] [warning] [vscode.emmet] Accessing a resource scoped configuration without providing a resource is not expected. To get the effective value for 'emmet.includeLanguages', provide the URI of a resource or 'null' for any resource.

When opening a Jinja HTML file:
nothing new

Switching to built in HTML language:

[2022-09-09 18:12:10.034] [exthost] [info] ExtensionService#_doActivateExtension vscode.html-language-features, startup: false, activationEvent: 'onLanguage:html'

[aeschli]

Hm, you are right. I initially thought we could just add an extensionDependency, but
a. that does not do activation (i just tried)
b. would force the handlebars/whatever extension to run on the same extension host as the rich html extension, which is not what we want.

You currently have add source code to your extension and activate the vscode.html-language-features in code

@alexdima Is there some other way to trigger an activation of an extension in a declarative way?

[devmattrick]

Thanks for the response! That's good to know, maybe I can use that as a temporary solution.

My thought on this is the htmlLanguageParticipants field pretty much implies that the html extension should activate when a language using it is opened. I think it'd be good ergonomics to have it do that by default, but I'm not familiar enough with Code's plugin architecture to know if that's feasible. Either way, thank you for looking into this!

[aeschli]

My thought on this is the htmlLanguageParticipants field pretty much implies that the html extension should activate when a language using it is opened.

Good suggestion, yes, we could auto-activate the HTML extension so it can track the open editors to see if a participant language is used.