Extensions never be activated after granting workspace trust

[testforstephen]

• VS Code Version:
  Version: 1.58.0-insider
  Commit: 3caebff
  Date: 2021-06-24T05:14:29.975Z
  Electron: 12.0.12
  Chrome: 89.0.4389.128
  Node.js: 14.16.0
  V8: 8.9.255.25-electron.0
  OS: Darwin x64 19.6.0
• OS Version: macOS Catalina 10.15.7

Steps to Reproduce:

1. Open a new workspace and make it untrusted by default. Then use "Manage workspace trust" to trust the workspace.
2. Observe the extensions state in extensions view. Those extensions without declaring support for workspace trust are still grayed out. And those that are supposed to be activated in trusted workspace are not activated either.

workspace-trust.mov

This issue only exists in latest insider, but works in the stable VS Code.

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Support trusted workspace settings (#120860)
• Workspace trust - empty workspace (#123811)
• Workspace trust - improve settings discoverability (#126361)
• Workspace trust extension API (#120173)
• I can use an extension when a workspace transitions from trust -> untrusted (#125526)

[lszomoru]

@testforstephen, issue should be fixed in the next Insiders build.

[dboreham]

fwiw I still have this issue (or at least the specific version of it reported in #127012) today, running what I believe should be a build with the fix:

Version: 1.58.0-insider (user setup)
Commit: 9056b400b527c562871093916081c3e6df2691dd
Date: 2021-07-03T07:56:10.923Z
Electron: 12.0.13
Chrome: 89.0.4389.128
Node.js: 14.16.0
V8: 8.9.255.25-electron.0
OS: Windows_NT x64 10.0.22000

[2021-07-04 11:24:36.867] [exthost] [error] ProxyResolver#resolveProxy Canceled: Canceled
	at Object.i [as canceled] (c:\Users\david\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:5:1157)
	at u._remoteCall (c:\Users\david\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:88:12817)
	at Proxy._.<computed>.D.charCodeAt._.<computed> (c:\Users\david\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:88:9349)
	at D.resolveProxy (c:\Users\david\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:88:36547)
	at Object.resolveProxy (c:\Users\david\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:93:57068)
	at useProxySettings (c:\Users\david\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\node_modules.asar\vscode-proxy-agent\out\index.js:159:16)
	at c:\Users\david\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\node_modules.asar\vscode-proxy-agent\out\index.js:107:13
	at c:\Users\david\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\node_modules.asar\vscode-proxy-agent\out\index.js:335:13
	at processTicksAndRejections (internal/process/task_queues.js:93:5) 

[lszomoru]

@dboreham, I am unable to reproduce the problem in the latest Insiders release.
Could you please share the steps that you are using when running into the issue? Thanks!

[dboreham]

Hi, some testing reveals that the problem is only present in WSL2 and Container targets (it works ok against local Windows).

Reproduction:

1. Create an empty directory in WSL2.
2. Open a new VSCode window.
3. Select "Open folder in WSL2".
4. Pick the empty directory.
5. Click to trust the folder.
6. Install the "Scala Metala" VSCode extension.
7. Observe that the extension is disabled for mysterious reasons.

This setup worked prior to a recent VSCode insiders update, so I am assuming we're looking at a symptom of the same problem, although it's also possible something specific to the Scala extensions is causing a different problem with similar symptoms. I don't see anything terribly useful in the logs, just the same error pasted above.

Not working case (remote, WSL2):

Working (local, Windows):

[lszomoru]

Thanks @dboreham for the steps. I was able to reproduce the problem on my side, but I do not believe that this is necessarily related to workspace trust. I am able to reproduce the issue even after I have disable the workspace trust feature using the security.workspace.trust.enabled setting.

If you hover over the warning icon for the Scala (Metals) extension, it looks like the extension is disabled because it depends on an extension (Scala Syntax (official)) that is currently being disabled. If you hover over the information icon for the Scala Syntax (official) extension, it looks like the extension is disabled in WSL because it is already enabled locally. @sandy081, is there anything obvious that I am missing?

[dboreham]

If you hover over the warning icon for the Scala (Metals) extension, it looks like the extension is disabled because it depends on an extension (Scala Syntax (official)) that is currently being disabled. If you hover over the information icon for the Scala Syntax (official) extension, it looks like the extension is disabled in WSL because it is already enabled locally. @sandy081, is there anything obvious that I am missing?

I did some testing with non-insiders VSCode. What I see there is that initially the scala syntax extension is also in the "installed globally so disabled" state, however a popup appears saying something like "metals needs scala extension, would you like it downloaded?". Click yes, and after some gears turning it appears to be working. That popup never appears in the insiders case.

I'll file a bug against the metals project...

[dboreham]

@lszomoru metals folks are saying this is a VSCode bug (and actively closing every bug filed for this issue, I discovered):
scalameta/metals-vscode#613 and scalameta/metals-vscode#605
I'll see if I can find any open issue in this project for this, or else open one.

[sandy081]

however a popup appears saying something like "metals needs scala extension, would you like it downloaded?"

Can you please copy/paste this pop up?

[dboreham]

however a popup appears saying something like "metals needs scala extension, would you like it downloaded?"

Can you please copy/paste this pop up?

This took a bit of work because you have to completely uninstall both extensions to get it back into the right state:

For clarity: I do not ever see this popup in VSCode Insiders, although that could be because the system isn't in the correct state to prompt the popup. I will try to see if I can make it come up in Insiders by uninstalling extensions, re-starting..

[dboreham]

I tried again to see if I could get the popup to show in VSCode insiders by uninstalling, restarting. No luck.
I also compared the logs between the Insiders and regular VSCode cases, and I didn't see any significant difference there.
Log looks like this:

[2021-07-08 11:24:46.646] [remoteagent] [info] Installing extension: scalameta.metals
[2021-07-08 11:24:47.444] [remoteagent] [info] Installing extension: scala-lang.scala
[2021-07-08 11:24:47.478] [remoteagent] [info] Downloaded extension: scala-lang.scala /home/david/.vscode-server-insiders/data/CachedExtensionVSIXs/scala-lang.scala-0.5.3
[2021-07-08 11:24:47.503] [remoteagent] [info] Removed the extension from uninstalled list: scala-lang.scala
[2021-07-08 11:24:47.508] [remoteagent] [info] Extensions installed successfully: scala-lang.scala
[2021-07-08 11:24:47.542] [remoteagent] [info] Downloaded extension: scalameta.metals /home/david/.vscode-server-insiders/data/CachedExtensionVSIXs/scalameta.metals-1.10.6
[2021-07-08 11:24:47.565] [remoteagent] [info] Removed the extension from uninstalled list: scalameta.metals
[2021-07-08 11:24:47.570] [remoteagent] [info] Extensions installed successfully: scalameta.metals

[sandy081]

This popup says that Scala (Metals) extension got activated but it's dependency Scala Syntax (official) extension is not enabled. This is an error coming from VS Code and ideally VS Code should not be activating the extension when its dependencies are not there.

We enhanced VS Code recently to fix this error by not enabling the extension when its dependencies are not enabled - #122448. Thats why you do not see the prompt in insiders.

To know the root cause may I know why Scala Syntax (official) extension is disabled? You can check it by hovering on the extension.

[dboreham]

To know the root cause may I know why Scala Syntax (official) extension is disabled? You can check it by hovering on the extension.

Hover over only says that it is disabled, not why.

I have a theory as to why, testing it now...

[dboreham]

I have a theory as to why, testing it now...

Nope, it wasn't that. (I noticed another extension complain that it needed JDK11, while I had switched to JDK8 on WSL2 recently, but after reverting to JDK11 in WSL2 the scalametals extension problem remains).

[dboreham]

Digging into this some more: it appears that VSCode disabling the scala-lang plugin for remote is expected behavior. That extension is defined as of kind UI: https://github.com/scala/vscode-scala-syntax/blob/99868aa9177f33b9bd7dce2ea0d1b25e37e6899c/package.json#L11

So the question is probably not why is scala-lang disabled, but why does VSCode think that it needs to be enabled remote as a dependency of scalametals?

Also btw I noticed that the problem has crept into non-insiders VSCode now. It updated, so perhaps that's the reason, or perhaps there is a bad state causing the problem that wasn't initially present when I first downloaded VSCode this morning.

Version: 1.58.0 (user setup)
Commit: 2d23c42a936db1c7b3b06f918cde29561cc47cd6
Date: 2021-07-08T06:54:55.083Z
Electron: 12.0.13
Chrome: 89.0.4389.128
Node.js: 14.16.0
V8: 8.9.255.25-electron.0
OS: Windows_NT x64 10.0.22000

[dboreham]

Update: I found another computer that had working VSCode Insiders with working scalametals extension.
Using this system, by updating VSCode, I confirmed that something breaks scalametals between the following versions (first one works, second one does not):

Version: 1.57.0-insider (user setup)
Commit: b4c1bd0a9b03c749ea011b06c6d2676c8091a70c
Date: 2021-06-09T11:49:36.076Z
Electron: 12.0.9
Chrome: 89.0.4389.128
Node.js: 14.16.0
V8: 8.9.255.25-electron.0
OS: Windows_NT x64 10.0.22000

Version: 1.58.0-insider (user setup)
Commit: 2d23c42a936db1c7b3b06f918cde29561cc47cd6
Date: 2021-07-07T12:09:55.219Z
Electron: 12.0.13
Chrome: 89.0.4389.128
Node.js: 14.16.0
V8: 8.9.255.25-electron.0
OS: Windows_NT x64 10.0.22000

(btw I did not do anything other than allow VSCode to update -- previously working scala projects stopped working after the update).

[tgodzik]

Isn't the reason for the issue the fact the scala-syntax is a UI extension so it is on the local machine and Metals works on the remote one? It seems they are on different "machines", so VS Code might not be detecting scala-syntax on a remote machine, which is why it's disabling Metals there.

So essentially, this a false negative caused by #122448 ?

[dboreham]

Isn't the reason for the issue the fact the scala-syntax is a UI extension so it is on the local machine and Metals works on the remote one? It seems they are on different "machines", so VS Code might not be detecting scala-syntax on a remote machine, which is why it's disabling Metals there.

So essentially, this a false negative caused by #122448 ?

I wondered about that, and to test the theory went looking for other extensions that might follow the same pattern. I couldn't find an example in my fairly large set of installed extensions where a remote plugin depends on a UI plugin, but I did find an example of a UI plugin "disabled" remote:

It displays with the same status as the scala-lang extension, but no other remote extension depends on it:

Conversely, I wondered about this pair of extensions which you'd think would be similarly afflicted:

But it appears the Haskell syntax extension is different vs Scala in that it is remote-only, and shows as disabled local:

[juan-valderrama]

Adding the remote extension behavior in my settings.json fixed the issue for me
"remote.extensionKind": { "scala-lang.scala": [ "workspace" ] }

[tgodzik]

It seems that the Haskell syntax extension doesn't declare extensionKind, so I would say that the theory holds. Remote workspace extensions should be allowed to depend on local UI ones.

This should most likely be fixed in VS Code, we can alternatively remove extensionKind from Scala extension, but that would be a workaround.

Edit: Is there an issue for that?

[dboreham]

The long, good fix is fine for me because I reverted to VSCode 1.57 for the time being.

[dboreham]

Adding the remote extension behavior in my settings.json fixed the issue for me
"remote.extensionKind": { "scala-lang.scala": [ "workspace" ] }

Thanks, I'd seen that in the doc and wondered if it would help, but hadn't tried it.

[tgodzik]

Opened a new issue here: #128375

[sandy081]

@dboreham and @tgodzik Thanks for the provided info. It seems there is a change in the behaviour and let's discuss in the newly opened issue.