jiebi/CodeConvo huggingface dataset:
Code change:
Type: <bBug</bVSCode, create a folder named, for instance, "XXXX". that folder create another called .vscode .vscode create a file named with this content: VSCode sure the setting "task.allowAutomaticTasks" is not set or is set to its defautl value "auto". "XXXX" with VSCode. VSCode will run "echo Hello" without asking you whether you want to run tasks configured with "runOn": "folderOpen" or not. VS Code version: Code 1.70.2 (, 2022-08-16T05:35:13.448Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This happens because you have presumably opened a trusted workspace - which is now when we allow these to be run if the setting is "auto" for allow automatic task
The described behavior is how it is expected to work. If you disagree, please explain what is expected and what is not in more detail. See also our . Happy Coding!
! If I understood it correctly, the popup that supposedly asks you whether you want to run these tasks is not actually meant to appear ever because if the workspace is trusted it will be executed without asking you and if it is not trusted then it will just not exeute them instead of asking you. Doesn't it look kinda pointless to have in the description of the option of the configuration "Prompt for permission for each folder"? You are never prompted anyways.
I this configuration and I am still not prompted anyways:
No I did not. Please next time ask the user if he did X before assuming it and closing the issue. I tried reproducing the problem with and without a trusted workspace and the problem persists anyways.
i'll investigate this that shouldn't happen
Tasks will only run in trusted workspaces, so I will update the setting description to indicate that. Also need to fix the prompt not happening per folder.

Related discussion:
text: } if (runSource === TaskRunSource.User) { const workspaceTasks = await this.getWorkspaceTasks(); <del> RunAutomaticTasks.promptForPermission(this, this._storageService, this._notificationService, this._workspaceTrustManagementService, this._openerService, this._configurationService, workspaceTasks); </del> <ins> RunAutomaticTasks.runWithPermission(this, this._storageService, this._notificationService, this._workspaceTrustManagementService, this._openerService, this._configurationService, workspaceTasks); </ins> } return executeTaskResult; } catch (error) {
Code change:
Type: <bBug</bVSCode, create a folder named, for instance, "XXXX". that folder create another called .vscode .vscode create a file named with this content: VSCode sure the setting "task.allowAutomaticTasks" is not set or is set to its defautl value "auto". "XXXX" with VSCode. VSCode will run "echo Hello" without asking you whether you want to run tasks configured with "runOn": "folderOpen" or not. VS Code version: Code 1.70.2 (, 2022-08-16T05:35:13.448Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This happens because you have presumably opened a trusted workspace - which is now when we allow these to be run if the setting is "auto" for allow automatic task
The described behavior is how it is expected to work. If you disagree, please explain what is expected and what is not in more detail. See also our . Happy Coding!
! If I understood it correctly, the popup that supposedly asks you whether you want to run these tasks is not actually meant to appear ever because if the workspace is trusted it will be executed without asking you and if it is not trusted then it will just not exeute them instead of asking you. Doesn't it look kinda pointless to have in the description of the option of the configuration "Prompt for permission for each folder"? You are never prompted anyways.
I this configuration and I am still not prompted anyways:
No I did not. Please next time ask the user if he did X before assuming it and closing the issue. I tried reproducing the problem with and without a trusted workspace and the problem persists anyways.
i'll investigate this that shouldn't happen
Tasks will only run in trusted workspaces, so I will update the setting description to indicate that. Also need to fix the prompt not happening per folder.

Related discussion:
text: @ITaskService private readonly _taskService: ITaskService, @IConfigurationService private readonly _configurationService: IConfigurationService, @IWorkspaceTrustManagementService private readonly _workspaceTrustManagementService: IWorkspaceTrustManagementService, <del> @ILogService private readonly _logService: ILogService) { </del> <ins> @ILogService private readonly _logService: ILogService, @IStorageService private readonly _storageService: IStorageService, @IOpenerService private readonly _openerService: IOpenerService, @INotificationService private readonly _notificationService: INotificationService) { </ins> super(); this._tryRunTasks(); }
Code change:
Type: <bBug</bVSCode, create a folder named, for instance, "XXXX". that folder create another called .vscode .vscode create a file named with this content: VSCode sure the setting "task.allowAutomaticTasks" is not set or is set to its defautl value "auto". "XXXX" with VSCode. VSCode will run "echo Hello" without asking you whether you want to run tasks configured with "runOn": "folderOpen" or not. VS Code version: Code 1.70.2 (, 2022-08-16T05:35:13.448Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This happens because you have presumably opened a trusted workspace - which is now when we allow these to be run if the setting is "auto" for allow automatic task
The described behavior is how it is expected to work. If you disagree, please explain what is expected and what is not in more detail. See also our . Happy Coding!
! If I understood it correctly, the popup that supposedly asks you whether you want to run these tasks is not actually meant to appear ever because if the workspace is trusted it will be executed without asking you and if it is not trusted then it will just not exeute them instead of asking you. Doesn't it look kinda pointless to have in the description of the option of the configuration "Prompt for permission for each folder"? You are never prompted anyways.
I this configuration and I am still not prompted anyways:
No I did not. Please next time ask the user if he did X before assuming it and closing the issue. I tried reproducing the problem with and without a trusted workspace and the problem persists anyways.
i'll investigate this that shouldn't happen
Tasks will only run in trusted workspaces, so I will update the setting description to indicate that. Also need to fix the prompt not happening per folder.

Related discussion:
text: type: 'string', enum: ['on', 'auto', 'off'], enumDescriptions: [ <del> nls.localize('ttask.allowAutomaticTasks.on', "Always"), </del> <ins> nls.localize('task.allowAutomaticTasks.on', "Always"), </ins> nls.localize('task.allowAutomaticTasks.auto', "Prompt for permission for each folder"), nls.localize('task.allowAutomaticTasks.off', "Never"), ], <del> description: nls.localize('task.allowAutomaticTasks', "Enable automatic tasks in the folder."), </del> <ins> description: nls.localize('task.allowAutomaticTasks', "Enable automatic tasks in the folder - note that tasks won't run in an untrusted workspace."), </ins> default: 'auto', restricted: true },
Code change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Noticed that SourcePawn extension has this feature, it should be enabled for built-in C/C++ preprocessor #if and #endif, just like for brackets [] () {} SourcePawn: ! C/C++: ! Could probably be done for other languages that have keywords rather than braces for opening and closing a block, e.g. Lua's if-then-end: !
Not sure if this is editor or C/C++ language config / text mate.
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
Hello there,is this issue open?If so,could i work on this?
Should make request to Just add as brackets to !
This change should be reverted if it can't be made work with all the other preprocessor statements that match the endif: #if, #ifdef, #ifndef, #else, #elif, #elifdef, #elifndef, see matching isn't required, but it shouldn't show the #endif as unmatched.
it'll work fine with the rest of the #if's just #else etc won't work as vscode doesn't support inside/middle brackets but it won't cause any issues
ah..... one thing I forgot about ! bit of a deal breaker vscode would have to support 'transcendent' brackets similar problem to
Oh -- that seems like a different bug? ! -- The red }, not sure how you got the red {. It doesn't repro with VS Code (non-Insiders). Repro code is Should someone file a new bug on that or is it the same root issue?
Yeah, looks like the PR at fixes it though.
Thanks for reporting this! We will revert the PR as it causes too many unexpected issues. If you like to have this, you can configure the brackets to colorize in the user settings.
Okay, I figured it out via The directives remain the unmatched color.
We closed this issue because we 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 and . Thanks for your understanding, and happy coding!

Related discussion:
text: "brackets": [ ["{", "}"], ["[", "]"], <del> ["(", ")"] </del> <ins> ["(", ")"], ["#if","#endif"], </ins> ], "autoClosingPairs": [ { "open": "[", "close": "]" },
Code change:
<img width="584" alt="image" src="https://user-"//cc for views
I assume this is nothing to do with the views instead its about how entires are rendered in list/tree. CC
Tree row contents are outside of the tree's jurisdiction, but are in fact responsibility of the widget user.
Timeline doesn't use the extension tree view and instead does it's own thing. I think works on timeline.
curious, do we have an understanding what caused this? it seems relatively recent?
Might be related to . any ideas here?
It was caused by , can you check? I see a visual difference not only with the alignment but also the spacing: Before <img width="254" alt="image" src="https://user-"After <img width="269" alt="image" src="https://user-"
it looks like timeline relies on the custom tree view css. I made a change in the nesting/ordering of elements in the tree view recently and I updated the css to reflect that. Because timeline relies on the css but doesn't actually use the custom tree view, this broke the timeline. I've opened a PR with a timeline specific css fix.
<!-- UNABLETOLOCATECOMMITMESSAGE issue --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased

Related discussion:
text: .customview-tree .monaco-list .monaco-list-row .custom-view-tree-node-item { display: flex; <ins> align-items: center; </ins> height: 22px; line-height: 22px; flex: 1;
Code change:
<img width="584" alt="image" src="https://user-"//cc for views
I assume this is nothing to do with the views instead its about how entires are rendered in list/tree. CC
Tree row contents are outside of the tree's jurisdiction, but are in fact responsibility of the widget user.
Timeline doesn't use the extension tree view and instead does it's own thing. I think works on timeline.
curious, do we have an understanding what caused this? it seems relatively recent?
Might be related to . any ideas here?
It was caused by , can you check? I see a visual difference not only with the alignment but also the spacing: Before <img width="254" alt="image" src="https://user-"After <img width="269" alt="image" src="https://user-"
it looks like timeline relies on the custom tree view css. I made a change in the nesting/ordering of elements in the tree view recently and I updated the css to reflect that. Because timeline relies on the css but doesn't actually use the custom tree view, this broke the timeline. I've opened a PR with a timeline specific css fix.
<!-- UNABLETOLOCATECOMMITMESSAGE issue --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased

Related discussion:
text: display: block; } <ins> .timeline-tree-view .monaco-list .monaco-list-row .custom-view-tree-node-item > .custom-view-tree-node-item-icon, </ins> .customview-tree .monaco-list .monaco-list-row .custom-view-tree-node-item > .custom-view-tree-node-item-resourceLabel > .custom-view-tree-node-item-icon { background-size: 16px; background-position: left center;
Code change:
<img width="584" alt="image" src="https://user-"//cc for views
I assume this is nothing to do with the views instead its about how entires are rendered in list/tree. CC
Tree row contents are outside of the tree's jurisdiction, but are in fact responsibility of the widget user.
Timeline doesn't use the extension tree view and instead does it's own thing. I think works on timeline.
curious, do we have an understanding what caused this? it seems relatively recent?
Might be related to . any ideas here?
It was caused by , can you check? I see a visual difference not only with the alignment but also the spacing: Before <img width="254" alt="image" src="https://user-"After <img width="269" alt="image" src="https://user-"
it looks like timeline relies on the custom tree view css. I made a change in the nesting/ordering of elements in the tree view recently and I updated the css to reflect that. Because timeline relies on the css but doesn't actually use the custom tree view, this broke the timeline. I've opened a PR with a timeline specific css fix.
<!-- UNABLETOLOCATECOMMITMESSAGE issue --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased

Related discussion:
text: .customview-tree .monaco-list .monaco-list-row .custom-view-tree-node-item .custom-view-tree-node-item-resourceLabel::after { padding-right: 0px; <ins> margin-right: 4px; </ins> } .customview-tree .monaco-list .monaco-list-row .custom-view-tree-node-item .actions {
Code change:
Chinese (Simplified) : <img width="321" alt="image" src="https://user-"English : <img width="272" alt="image" src="https://user-""Create Manual Folding Ranges from Selection" is not in Command Palette when use Chinese (Simplified) VSCode Version: 1.71.0 (both macOS & Win10) Chinese (Simplified) Version: 1.71.
Thank you for your feedback. We are currently reviewing it (reference ).
Could you please assist here? Thank you.
The problem is this label: should accept an  but it only accepts a string. deeper: and deeper:
The workaround is to use  to find this item.

Related discussion:
text: super({ id: 'editor.createFoldingRangeFromSelection', label: nls.localize('createManualFoldRange.label', "Create Manual Folding Range from Selection"), <del> alias: 'Create Folding Range from Selection', </del> <ins> alias: 'Create Manual Folding Range from Selection', </ins> precondition: CONTEXT_FOLDING_ENABLED, kbOpts: { kbExpr: EditorContextKeys.editorTextFocus,
Code change:
GitHub Tags:#A11yMAS;#A11yTCS;#A11ySev2;#DesktopApp;#Win32;#Visual Studio Code Client;#BM-VisualStudioCodeClient-Win32-Aug2022;#WCAG1.3.1;#NVDA; #ScreenReader;#JAWS;#AILimited;#Element:Button; Application Name: Visual Studio Live Share Application version: 1.56.2 (user setup) Windows Version: Win10 VS Code a project (e.g., vsls-guestbook) in VSCode. till “sign in” button. till "Live share" under Extensions and hit enter on the NVDA and tab to drop down 'Visual Studio live share work' screen. The label of the 'Visual Studio live share work….' is being read as 'folder section button' when the screen reader focus moves to it using tab key. Similar issue is observed with JAWS. The screen reader should read it as 'Visual Studio live share work button' when screen reader focus moves to it. People who uses screen reader may face difficulty while activating an object when the accessible label is different than that of the visible labels. https://user-
logged for primary bug
I think this issue makes sense. In short - aria label of the explorer view should contain the name of the top folder. Currently it is just "Folders". So it should be dynamic. Assigning to
Actually not too sure how to fix this one. The section being read out is the static section name of the view pane We do have an aria label within that section header with the name of the folder which dynamically updates but that never gets focused. The pane registration is static and we don't know the folder name at that time
there's the  method in the . Update header should set the aria label of the header. And the explorer should call updateHeader every time the content of the header changes (which it might do already).
could you please the bug in open state the bug can be closed only by trusted tester after verification right now the fix is not present in the app Version: 1.72.0-insider (user setup) Commit: Date: 2022-09-23T05:17:37.024Z Electron: 19.0.17 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes !
please look at the label that the VS Code bot has to the issue. It says "unreleased". Once the bot adds the label "released" that means the fix is present. We can not leave the issue open for the tester to close this since this does not align with the rest of our VS Code processes. In case the bug is not fixed after it is released, just comment on the issue and we will reopen it. Thanks!
GitHubTags:#Closed;

Related discussion:
text: private _headerVisible = true; private _minimumBodySize: number; private _maximumBodySize: number; <del> private ariaHeaderLabel: string; </del> <ins> private _ariaHeaderLabel: string; </ins> private styles: IPaneStyles = {}; private animationTimer: number | undefined = undefined;
Code change:
GitHub Tags:#A11yMAS;#A11yTCS;#A11ySev2;#DesktopApp;#Win32;#Visual Studio Code Client;#BM-VisualStudioCodeClient-Win32-Aug2022;#WCAG1.3.1;#NVDA; #ScreenReader;#JAWS;#AILimited;#Element:Button; Application Name: Visual Studio Live Share Application version: 1.56.2 (user setup) Windows Version: Win10 VS Code a project (e.g., vsls-guestbook) in VSCode. till “sign in” button. till "Live share" under Extensions and hit enter on the NVDA and tab to drop down 'Visual Studio live share work' screen. The label of the 'Visual Studio live share work….' is being read as 'folder section button' when the screen reader focus moves to it using tab key. Similar issue is observed with JAWS. The screen reader should read it as 'Visual Studio live share work button' when screen reader focus moves to it. People who uses screen reader may face difficulty while activating an object when the accessible label is different than that of the visible labels. https://user-
logged for primary bug
I think this issue makes sense. In short - aria label of the explorer view should contain the name of the top folder. Currently it is just "Folders". So it should be dynamic. Assigning to
Actually not too sure how to fix this one. The section being read out is the static section name of the view pane We do have an aria label within that section header with the name of the folder which dynamically updates but that never gets focused. The pane registration is static and we don't know the folder name at that time
there's the  method in the . Update header should set the aria label of the header. And the explorer should call updateHeader every time the content of the header changes (which it might do already).
could you please the bug in open state the bug can be closed only by trusted tester after verification right now the fix is not present in the app Version: 1.72.0-insider (user setup) Commit: Date: 2022-09-23T05:17:37.024Z Electron: 19.0.17 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes !
please look at the label that the VS Code bot has to the issue. It says "unreleased". Once the bot adds the label "released" that means the fix is present. We can not leave the issue open for the tester to close this since this does not align with the rest of our VS Code processes. In case the bug is not fixed after it is released, just comment on the issue and we will reopen it. Thanks!
GitHubTags:#Closed;

Related discussion:
text: private readonly _onDidChangeExpansionState = this._register(new Emitter<boolean>()); readonly onDidChangeExpansionState: Event<boolean> = this._onDidChangeExpansionState.event; <ins> get ariaHeaderLabel(): string { return this._ariaHeaderLabel; } set ariaHeaderLabel(newLabel: string) { this._ariaHeaderLabel = newLabel; this.header.setAttribute('aria-label', this.ariaHeaderLabel); } </ins> get draggableElement(): HTMLElement { return this.header; }