jiebi/CodeConvo huggingface dataset:
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: super(); this._expanded = typeof options.expanded === 'undefined' ? true : !!options.expanded; this._orientation = typeof options.orientation === 'undefined' ? Orientation.VERTICAL : options.orientation; <del> this.ariaHeaderLabel = localize('viewSection', "{0} Section", options.title); </del> <ins> this._ariaHeaderLabel = localize('viewSection', "{0} Section", options.title); </ins> this._minimumBodySize = typeof options.minimumBodySize === 'number' ? options.minimumBodySize : this._orientation === Orientation.HORIZONTAL ? 200 : 120; this._maximumBodySize = typeof options.maximumBodySize === 'number' ? options.maximumBodySize : Number.POSITIVE_INFINITY;
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: const title = workspace.folders.map(folder => folder.name).join(); titleElement.textContent = this.name; titleElement.title = title; <del> titleElement.setAttribute('aria-label', nls.localize('explorerSection', "Explorer Section: {0}", this.name)); </del> <ins> this.ariaHeaderLabel = nls.localize('explorerSection', "Explorer Section: {0}", this.name); titleElement.setAttribute('aria-label', this.ariaHeaderLabel); </ins> }; this._register(this.contextService.onDidChangeWorkspaceName(setHeader));
Code change:
Type: <bBug</bI saw the schema prompt for 'types' under terminal contribute, but setting it does not take effect. After checking the vscode source code and issue, I found that this contribution point has been removed. VS Code version: Code 1.71.0 (Universal) (, 2022-09-01T07:25:38.437Z) OS version: Darwin x64 21.4.0 Modes: Sandboxed: No Remote OS version: Linux x64 5.10.3+ <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
!
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.71.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Related Links:
After upgrading to , it still remain.

Related discussion:
text: description: nls.localize('vscode.extension.contributes.terminal', 'Contributes terminal functionality.'), type: 'object', properties: { <del> types: { type: 'array', description: nls.localize('vscode.extension.contributes.terminal.types', "Defines additional terminal types that the user can create."), items: { type: 'object', required: ['command', 'title'], properties: { command: { description: nls.localize('vscode.extension.contributes.terminal.types.command', "Command to execute when the user creates this type of terminal."), type: 'string', }, title: { description: nls.localize('vscode.extension.contributes.terminal.types.title', "Title for this type of terminal."), type: 'string', }, icon: { description: nls.localize('vscode.extension.contributes.terminal.types.icon', "A codicon, URI, or light and dark URIs to associate with this terminal type."), anyOf: [{ type: 'string', }, { type: 'object', properties: { light: { description: nls.localize('vscode.extension.contributes.terminal.types.icon.light', 'Icon path when a light theme is used'), type: 'string' }, dark: { description: nls.localize('vscode.extension.contributes.terminal.types.icon.dark', 'Icon path when a dark theme is used'), type: 'string' } } }] }, }, }, }, </del> profiles: { type: 'array', description: nls.localize('vscode.extension.contributes.terminal.profiles', "Defines additional terminal profiles that the user can create."),
Code change:
Locally I have an empty cell at the bottom of my notebook because I executed the last cell When I try to merge in a change that has new cells, I get a merge conflict that requires I open the ipynb in a text editor to resolve. !
We can explore how to handle this gracefully in the serializer.
not sure what needs to be done in the serializer here. can you provide more information, i would have thought this was purely an issue with merge conflicts.
Can this please be solved? It's hard to work collaboratively within a team using Jupyter notebooks and VS Code if we can't sort out merge conflicts.
I suggest there be an option to disable the notebook renderer temporarily in all editors. git operates at the text level and when merge conflict happens, it will likely produce a malformed JSON file. We now have an error message to notify users to fallback to text editor, but "resolve in merge editor" button still don't work. !
Note: When there are merge conflicts, one will always have to open a plain text (json) editor to resolve the merge confligs I.e. its not possible to use Notebook UI to resolve merge conflicts (at least not yet) Steps to test Ensure you have merge conflicts in a Notebook document Open the SCM view, and click on the IPYNB file, and verify you can see the merge conflicts in plain text editor view Click on the button and verify you get the merge editor (again plain text), see here When you have merge conflicts, try opening the ipynb file from the explorer view, if this fails verify you are displayed with an error message with the option to open the file in plain text view

Related discussion:
text: import { Disposable, DisposableStore, IDisposable, toDisposable } from 'vs/base/common/lifecycle'; import { ResourceMap } from 'vs/base/common/map'; import { Schemas } from 'vs/base/common/network'; <del> import { isEqual } from 'vs/base/common/resources'; </del> <ins> import { basename, isEqual } from 'vs/base/common/resources'; </ins> import { isDefined } from 'vs/base/common/types'; import { URI } from 'vs/base/common/uri'; import { IAccessibilityService } from 'vs/platform/accessibility/common/accessibility';
Code change:
Locally I have an empty cell at the bottom of my notebook because I executed the last cell When I try to merge in a change that has new cells, I get a merge conflict that requires I open the ipynb in a text editor to resolve. !
We can explore how to handle this gracefully in the serializer.
not sure what needs to be done in the serializer here. can you provide more information, i would have thought this was purely an issue with merge conflicts.
Can this please be solved? It's hard to work collaboratively within a team using Jupyter notebooks and VS Code if we can't sort out merge conflicts.
I suggest there be an option to disable the notebook renderer temporarily in all editors. git operates at the text level and when merge conflict happens, it will likely produce a malformed JSON file. We now have an error message to notify users to fallback to text editor, but "resolve in merge editor" button still don't work. !
Note: When there are merge conflicts, one will always have to open a plain text (json) editor to resolve the merge confligs I.e. its not possible to use Notebook UI to resolve merge conflicts (at least not yet) Steps to test Ensure you have merge conflicts in a Notebook document Open the SCM view, and click on the IPYNB file, and verify you can see the merge conflicts in plain text editor view Click on the button and verify you get the merge editor (again plain text), see here When you have merge conflicts, try opening the ipynb file from the explorer view, if this fails verify you are displayed with an error message with the option to open the file in plain text view

Related discussion:
text: const notebookDiffEditorInputFactory: DiffEditorInputFactoryFunction = ({ modified, original, label, description }) => { return { editor: NotebookDiffEditorInput.create(this._instantiationService, modified.resource!, label, description, original.resource!, notebookProviderInfo.id) }; }; <ins> const mergeEditorInputFactory: MergeEditorInputFactoryFunction = (mergeEditor: IResourceMergeEditorInput): EditorInputWithOptions => { return { editor: this._instantiationService.createInstance( MergeEditorInput, mergeEditor.base.resource, { uri: mergeEditor.input1.resource, title: mergeEditor.input1.label ?? basename(mergeEditor.input1.resource), description: mergeEditor.input1.description ?? '', detail: mergeEditor.input1.detail }, { uri: mergeEditor.input2.resource, title: mergeEditor.input2.label ?? basename(mergeEditor.input2.resource), description: mergeEditor.input2.description ?? '', detail: mergeEditor.input2.detail }, mergeEditor.result.resource ) }; }; </ins> const notebookFactoryObject: EditorInputFactoryObject = { createEditorInput: notebookEditorInputFactory, createDiffEditorInput: notebookDiffEditorInputFactory, createUntitledEditorInput: notebookUntitledEditorFactory, <ins> createMergeEditorInput: mergeEditorInputFactory </ins> }; const notebookCellFactoryObject: EditorInputFactoryObject = { createEditorInput: notebookEditorInputFactory,
Code change:
Fyi there is no long running shutdown support on web, so this warning gets printed on unload: <img width="955" alt="image" src="https://user-"
In web we probably cannot support the value.
This is still on
I cannot reproduce this, just to be sure this is on the latest
Yes, reproduces even with caches disabled: !

Related discussion:
text: import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { EditSessionsDataViews } from 'vs/workbench/contrib/editSessions/browser/editSessionsViews'; import { EditSessionsFileSystemProvider } from 'vs/workbench/contrib/editSessions/browser/editSessionsFileSystemProvider'; <del> import { isNative } from 'vs/base/common/platform'; </del> <ins> import { isNative, isWeb } from 'vs/base/common/platform'; </ins> import { VirtualWorkspaceContext, WorkspaceFolderCountContext } from 'vs/workbench/common/contextkeys'; import { CancellationToken, CancellationTokenSource } from 'vs/base/common/cancellation'; import { equals } from 'vs/base/common/objects';
Code change:
Fyi there is no long running shutdown support on web, so this warning gets printed on unload: <img width="955" alt="image" src="https://user-"
In web we probably cannot support the value.
This is still on
I cannot reproduce this, just to be sure this is on the latest
Yes, reproduces even with caches disabled: !

Related discussion:
text: } private async autoStoreEditSession() { <del> if (this.configurationService.getValue('workbench.experimental.cloudChanges.autoStore') === 'onShutdown') { </del> <ins> if (this.configurationService.getValue('workbench.experimental.cloudChanges.autoStore') === 'onShutdown' && !isWeb) { </ins> const cancellationTokenSource = new CancellationTokenSource(); await this.progressService.withProgress({ location: ProgressLocation.Window,
Code change:
Fyi there is no long running shutdown support on web, so this warning gets printed on unload: <img width="955" alt="image" src="https://user-"
In web we probably cannot support the value.
This is still on
I cannot reproduce this, just to be sure this is on the latest
Yes, reproduces even with caches disabled: !

Related discussion:
text: 'type': 'string', 'tags': ['experimental', 'usesOnlineServices'], 'default': 'off', <del> 'markdownDescription': localize('autoStoreWorkingChangesDescription', "Controls whether to automatically store available working changes in the cloud for the current workspace."), </del> <ins> 'markdownDescription': localize('autoStoreWorkingChangesDescription', "Controls whether to automatically store available working changes in the cloud for the current workspace. This setting has no effect in the web."), </ins> }, 'workbench.cloudChanges.autoResume': { enum: ['onReload', 'off'],
Code change:
Fyi there is no long running shutdown support on web, so this warning gets printed on unload: <img width="955" alt="image" src="https://user-"
In web we probably cannot support the value.
This is still on
I cannot reproduce this, just to be sure this is on the latest
Yes, reproduces even with caches disabled: !

Related discussion:
text: this.shouldShowViewsContext = EDIT_SESSIONS_SHOW_VIEW.bindTo(this.contextKeyService); this._register(this.fileService.registerProvider(EditSessionsFileSystemProvider.SCHEMA, new EditSessionsFileSystemProvider(this.editSessionsStorageService))); <del> this.lifecycleService.onWillShutdown((e) => e.join(this.autoStoreEditSession(), { id: 'autoStoreWorkingChanges', label: localize('autoStoreWorkingChanges', 'Storing current working changes...') })); </del> <ins> this.lifecycleService.onWillShutdown((e) => { if (this.configurationService.getValue('workbench.experimental.cloudChanges.autoStore') === 'onShutdown' && !isWeb) { e.join(this.autoStoreEditSession(), { id: 'autoStoreWorkingChanges', label: localize('autoStoreWorkingChanges', 'Storing current working changes...') }); } }); </ins> this._register(this.editSessionsStorageService.onDidSignIn(() => this.updateAccountsMenuBadge())); this._register(this.editSessionsStorageService.onDidSignOut(() => this.updateAccountsMenuBadge())); }
Code change:
Fyi there is no long running shutdown support on web, so this warning gets printed on unload: <img width="955" alt="image" src="https://user-"
In web we probably cannot support the value.
This is still on
I cannot reproduce this, just to be sure this is on the latest
Yes, reproduces even with caches disabled: !

Related discussion:
text: } private async autoStoreEditSession() { <del> if (this.configurationService.getValue('workbench.experimental.cloudChanges.autoStore') === 'onShutdown' && !isWeb) { const cancellationTokenSource = new CancellationTokenSource(); await this.progressService.withProgress({ location: ProgressLocation.Window, type: 'syncing', title: localize('store working changes', 'Storing working changes...') }, async () => this.storeEditSession(false, cancellationTokenSource.token), () => { cancellationTokenSource.cancel(); cancellationTokenSource.dispose(); }); } </del> <ins> const cancellationTokenSource = new CancellationTokenSource(); await this.progressService.withProgress({ location: ProgressLocation.Window, type: 'syncing', title: localize('store working changes', 'Storing working changes...') }, async () => this.storeEditSession(false, cancellationTokenSource.token), () => { cancellationTokenSource.cancel(); cancellationTokenSource.dispose(); }); </ins> } private registerViews() {
Code change:
Open terminal and run command After it finishes, there is a freeze. Some times I see window is not responding dialog Now type command Freezes again Here is the profile that is captured while running command Here is the profile that is captured while running command I have set to
getOutputMatch can be too expensive: ! Is some quick fix not working on just a small line range?
The second one: !
Oh none of the quick fixes use offset or length currently. We should force that, otherwise the regex will run on every line.

Related discussion:
text: addNewLine?: boolean; } <ins> /** * A matcher that runs on a sub-section of a terminal command's output */ </ins> export interface ITerminalOutputMatcher { <ins> /** * A string or regex to match against the unwrapped line. */ </ins> lineMatcher: string | RegExp; <del> anchor?: 'top' | 'bottom'; offset?: number; length?: number; </del> <ins> /** * Which side of the output to anchor the {@link offset} and {@link length} against. */ anchor: 'top' | 'bottom'; /** * How far from either the top or the bottom of the butter to start matching against. */ offset: number; /** * The number of rows to match against, this should be as small as possible for performance * reasons. */ length: number; </ins> } export interface IXtermTerminal {
Code change:
Open terminal and run command After it finishes, there is a freeze. Some times I see window is not responding dialog Now type command Freezes again Here is the profile that is captured while running command Here is the profile that is captured while running command I have set to
getOutputMatch can be too expensive: ! Is some quick fix not working on just a small line range?
The second one: !
Oh none of the quick fixes use offset or length currently. We should force that, otherwise the regex will run on every line.

Related discussion:
text: export function gitSimilarCommand(): ITerminalContextualActionOptions { return { commandLineMatcher: GitCommandLineRegex, <del> outputMatcher: { lineMatcher: GitSimilarOutputRegex, anchor: 'bottom' }, </del> <ins> outputMatcher: { lineMatcher: GitSimilarOutputRegex, anchor: 'bottom', offset: 0, length: 3 }, </ins> actionName: (matchResult: ContextualMatchResult) => matchResult.outputMatch ? `Run git ${matchResult.outputMatch[1]}` : ``, exitStatus: false, getActions: (matchResult: ContextualMatchResult, command: ITerminalCommand) => {
Code change:
Open terminal and run command After it finishes, there is a freeze. Some times I see window is not responding dialog Now type command Freezes again Here is the profile that is captured while running command Here is the profile that is captured while running command I have set to
getOutputMatch can be too expensive: ! Is some quick fix not working on just a small line range?
The second one: !
Oh none of the quick fixes use offset or length currently. We should force that, otherwise the regex will run on every line.

Related discussion:
text: return { actionName: (matchResult: ContextualMatchResult) => matchResult.outputMatch ? `Free port ${matchResult.outputMatch[1]}` : '', commandLineMatcher: AnyCommandLineRegex, <del> outputMatcher: !isWindows ? { lineMatcher: FreePortOutputRegex, anchor: 'bottom' } : undefined, </del> <ins> // TODO: Support free port on Windows https://github.com/microsoft/vscode/issues/161775 outputMatcher: isWindows ? undefined : { lineMatcher: FreePortOutputRegex, anchor: 'bottom', offset: 0, length: 20 }, exitStatus: false, </ins> getActions: (matchResult: ContextualMatchResult, command: ITerminalCommand) => { const port = matchResult?.outputMatch?.[1]; if (!port) {
Code change:
Open terminal and run command After it finishes, there is a freeze. Some times I see window is not responding dialog Now type command Freezes again Here is the profile that is captured while running command Here is the profile that is captured while running command I have set to
getOutputMatch can be too expensive: ! Is some quick fix not working on just a small line range?
The second one: !
Oh none of the quick fixes use offset or length currently. We should force that, otherwise the regex will run on every line.

Related discussion:
text: return { actionName: (matchResult: ContextualMatchResult) => matchResult.outputMatch ? `Git push ${matchResult.outputMatch[1]}` : '', commandLineMatcher: GitPushCommandLineRegex, <del> outputMatcher: { lineMatcher: GitPushOutputRegex, anchor: 'bottom' }, </del> <ins> outputMatcher: { lineMatcher: GitPushOutputRegex, anchor: 'bottom', offset: 0, length: 5 }, </ins> exitStatus: false, getActions: (matchResult: ContextualMatchResult, command: ITerminalCommand) => { const branch = matchResult?.outputMatch?.[1];