microsoft
Banner for workspace trust is not significant enough and themed as info-only
Does this issue occur when all extensions are disabled?: Yes/No
Version: 1.98.0-insider (system setup) Commit: 44028decf1ca81a0cbf99a65ab72cca6735449f2 Date: 2025-02-14T05:04:46.748Z Electron: 34.1.0 ElectronBuildId: 10990655 Chromium: 132.0.6834.194 Node.js: 20.18.1 V8: 13.2.152.38-electron.0 OS: Windows_NT x64 10.0.26120
Problem
NEW users to VS Code and our extension are getting challenges with Workspace Trust creating extensions in restricted mode and thus the commands for the extension are not visible to them. Our users are repeatably getting in to a state where the banner about workspace trust is not discernable as something as important that may be blocking their functionality. It is marked as a security banner (the keyhole badge), but it is 'info' themed:
This is very ignorable in the visual of a large screen. Even in our internal team case studies seasoned developers didn't see this as an important banner.
We have root-caused customer reports (https://github.com/microsoft/vscode-dotnettools/issues/1653) to our extension (that have been coming in at a sustaining pace) to this problem. This creates some new-user onboarding problems users exiting our workflow/funnels in getting in to the tool and our platform extension.
Proposal
We believe the banner should be more 'alert' styled and NOT themed with other color areas to remain CONSISTENT with the UX of an alert and not 'just a button' something like this:
Is a much more visible cue to take action/understand the repercussions of any prior choice. It changes no functionality but alerts the user better than what exists today and tests well as a visible alert to pay attention to that may affect their experience.
Not sure if red it the best choice here - since it is perfectly fine in some situations for users to browse repositories in restricted mode. Maybe yellow-warning is the right tone. Not sure.
fyi @kkbrooks
@lszomoru @sbatten it looks like we only have one style for banner, and info style, with a single color pair. I think we should consider adding warning and error state banners. This seems like it's a semi-blocking scenario, so a warning state seems appropriate.
Do we have any data on how many people are in restricted mode intentionally where changing the UI could potentially be obnoxious?
When a user opens a workspace they are presented with a dialog as to whether or not they should trust the workspace and then the banner persists. We do not know if the user ignore both of these messagings and is "unintentionally" in a restricted mode, but making the banner noisier seems excessive. From the scenario presented by dotnettools, I don't understand why a new project flow requires workspace trust to run the command. Does that command depend on the current workspace in any way?
@sbatten The extension both relies on code in the workspace as well as manipulate files in the workspace, both documented areas that indicate workspact trust is required. We also don't know why users are ignoring the dialog, but they are...and they are new users and dropping
@timheuer Are you disabling the extension all up? That's how I've been interpreting it, but an extension can reduce its feature set in an untrusted workspace to ensure that certain commands are still accessible such as "new project" https://code.visualstudio.com/api/extension-guides/workspace-trust#workspace-trust-api
Are you disabling the extension all up?
Right now yes, because we haven't adapted to the new APIs (see https://github.com/microsoft/vscode-dotnettools/issues/1774), but the blocker for us is this functionality is blocked based on the API/documentation -- so even as we reduce, the command wouldn't be exposed and our funnel still affected.
Our customers are not seeing that message is the bottom line...for some reason the dialog is ignored, and the banner is insufficient. The customers signal is that we are broken because the command we are telling them to use is missing. Even if we reduce, that command is still affected in this flow.
I don't follow... The command you are telling them to use is missing currently because you disable the entire extension. But if you were to enable the extension in untrusted mode, why would you still disable this command?
But if you were to enable the extension in untrusted mode
I do not believe per docs we can do this (we do workspace file manipulation). The command is "create a bunch of files in the workspace and modify others" basically -- I understand per docs that this cannot be done in untrusted workspace mode. That's the crux.
The command is missing because the whole extension is disabled. And the user's are reporting they are not seeing and/or understanding workspace trust mode impacting that...all they know is the functionality they are reading is missing.
The docs do not prescribe that you cannot do workspace file manipulation in untrusted mode. The workspace trust feature is not about protection from extensions but rather protection from malicious workspaces. The design recommendation we have is as follows (with some specifics to your scenario as I understand them):
- A feature/command that manipulates workspace file contents does not require workspace trust
- A feature/command that automatically executes code based on the contents of the workspace CAN be dangerous. This is nuanced. Showing spell checker errors runs code while reading the contents of the workspace but it is controlled by the extension, this does not require workspace trust. If the extension reads contents from a file and starts running the code to check for errors, that is dangerous and should require workspace trust.
- We recommend that all extensions who have a blend of features that do and do not require trust enable themselves with workspace trust, but guard features with the API.
Summary: 95% of your extension could require trust, but we still recommend enabling the extension and using the API to guard the features requiring trust.
https://code.visualstudio.com/api/extension-guides/workspace-trust#does-my-extension-treat-any-contents-of-the-workspace-as-code
The code we emit as a part of the command in the extension is code. Are you saying that we shouldn't require trust?
The code we emit as a part of the command in the extension is code
That's code you as the extension create, it doesn't come from the workspace the user gave you. But more importantly, generating code doesn't require trust, executing it does.
Thanks @sbatten -- I think by the letter of the law, we do 'execute' here because it's language code and our LSP kicks in, etc.
We'll look into adjusting our workspace trust, but the infobar here is still being missed, we still believe this is a valid adjustment that should be made. It's simply too ignorable as an 'infobar' -- else why not just put that state in the status bar then.
I think by the letter of the law, we do 'execute' here because it's language code and our LSP kicks in, etc.
Yes, this part is a bit grey and your call. Your LSP would only kick in once trust is granted, but generating the code doesn't. My understand how this would work:
- User opens new window which is untrusted
- User tries to run your command. They find it because the extension registers the command in an untrusted workspace.
- The new workspace is created without trust and you open the new workspace in a new window.
- In the new window, the user is prompted with a huge dialog that asks them to trust the workspace.
Them saying no at this point is not an error case, they may want to review the code and they should not be burdened with such a loud UX.
IMO, there is not sufficient evidence that the workspace trust dialog / banner is being ignored. If I as a user have a repo from some users fork open and I choose not to trust it, I do NOT want to trust the current workspace to access the "new project" command. Making it louder does not solve that problem.
IMO, there is not sufficient evidence that the workspace trust dialog / banner is being ignored.
For some reasons our new users are ignoring it. I'm sorry you can't accept that as data. I think this bar, which to me is meant to be alert-driven, is not shown in a way that I have to pay attention to it. It's themed and if I'm Hello Kitty themed, then it's going to be pink. It's hard to determine then what, if any, level of 'warning' I should discern from it if it is not standard UX guideline-driven aspects. It's well accepted that info/warn/error in the ecosystem of tools/dialogs/logs have meaning...and it's unclear to me what this is meant to convey then if just another themed banner.
I'd also argue then, given the justification, that this banner is not in accordance with the VS Code own UX Guidelines on Workspace status: https://code.visualstudio.com/api/ux-guidelines/status-bar:
displays information and actions that relate to your workspace. Items are placed into two groups: Primary (left) and Secondary (right). Items that relate to the entire workspace (status, problems/warnings, sync) go on the left
We'll continue to adjust our own extension, but I believe this small request to make it more in-line with the message it is trying to convey (heck it has a security shield even) isn't a big lift.
I hit this myself and was baffled at what was going on or what I needed to do. I get the challenges around styles and themes, but it just wasn't obvious enough for me.
For some reasons our new users are ignoring it. I'm sorry you can't accept that as data.
I say that I don't see this is sufficient evidence because all of the linked errors are around a command that should not require workspace trust.
I'd also argue then, given the justification, that this banner is not in accordance with the VS Code own UX Guidelines on Workspace status: https://code.visualstudio.com/api/ux-guidelines/status-bar:
The banner is not extension API.
@denelon Are you saying you hit this exact scenario? Or it was a different scenario related to the banner?
I was creating a new directory in the "terminal". I use VSCode routinely to look at/modify files. I attempted to open the folder with "code ." in the terminal. VSCode opened up, but since VSCode had not "seen" this folder before I was in a state where the "workspace" wasn't trusted.
When I didn't see the commands in the command palette, I closed VSCode and opened it again using the terminal. After doing that, the modal didn't render and the only visual clue I had was the narrow banner at the top. This could very easily be chocked up to user error in this case (sometimes things move, but I'll gladly take the blame on this one). Then when I attempted to launch again (up arrow in terminal to get "code ." back in my shell to launch VScode, VSCode launched, and the modal wasn't present, so I had no idea what to do next or what exactly needed attention.
Maybe launching the modal "every time" if the workspace isn't "trusted" that would help. I think the problem is I didn't understand why I was blocked, or more specifically what that means in the context of what I was attempting to do.
I was testing out this very scenario. I was looking for the "new project" in the command palette. When I didn't see that I had no idea it was because I was in restricted mode. There were other commands that showed up in the list. I was super confused. Maybe something in the list could have brought attention to the fact that not all commands are available when the workspace isn't trusted. Or maybe disable all commands to indicate the state of being in a not "trusted" workspace.
As @sbatten already mentioned, the workspace trust feature is not about protection from extensions but rather protection from malicious workspaces and the banner is intended to be informational after a customer has explicitly said they don't want to trust the authors.
It sounds like folks are getting confused when they aren't seeing specific commands in the command palette while in restricted mode. @sbatten would it be possible to show all commands, but have the ones they aren't able to use in restricted mode disabled? I think this would address @denelon's comments
Maybe launching the modal "every time" if the workspace isn't "trusted" that would help. I think the problem is I didn't understand why I was blocked, or more specifically what that means in the context of what I was attempting to do.
I was testing out this very scenario. I was looking for the "new project" in the command palette. When I didn't see that I had no idea it was because I was in restricted mode. There were other commands that showed up in the list. I was super confused. Maybe something in the list could have brought attention to the fact that not all commands are available when the workspace isn't trusted. Or maybe disable all commands to indicate the state of being in a not "trusted" workspace.
@kkbrooks I love this suggestion!! I think this would be a great start and after this if we are still getting reports that would be indicative of users still missing banner/struggling to get out of restricted mode.
Thank you all for your engagement here, seriously, I know I'm dying on my hill, but before we make adjustments here on the banner or what commands are shown in restricted mode, I want to reiterate what is confusing.
In this scenario, the confusion arises from the disconnect between what restricted mode is intended to disable and what is actually disabled. Let's imagine for a second that "New Jupyter Notebook" was disabled in Restricted mode. If I went looking for that command when in restricted mode, I would be confused for sure. Telling me via some UX in the command palette would definitely unblock me, but it would also send the wrong message. It would tell users they have to sacrifice security (allowing all sorts of other unrelated stuff to occur) to access secure features. Hence, we don't block secure features in restricted mode and users don't get confused.