jiebi/CodeConvo huggingface dataset:
Change:
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));

Discussion:
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;
Change:
import { IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { ServiceCollection } from 'vs/platform/instantiation/common/serviceCollection'; <del> import { ISCMHistoryProviderMenus, SCMHistoryItemTreeElement } from 'vs/workbench/contrib/scm/common/history'; </del> <ins> import { ISCMHistoryProviderMenus, SCMHistoryItemGroupTreeElement, SCMHistoryItemTreeElement } from 'vs/workbench/contrib/scm/common/history'; </ins> import { ISCMMenus, ISCMProvider, ISCMRepository, ISCMRepositoryMenus, ISCMResource, ISCMResourceGroup, ISCMService } from 'vs/workbench/contrib/scm/common/scm'; function actionEquals(a: IAction, b: IAction): boolean {

Discussion:
Testing I expected the action to appear on an unpublished branch, not the action. I am aware they both do the same. <img width="647" alt="Screenshot 2024-01-24 at 11 37 40" src=""
Change:
actual = replacePattern.buildReplaceString(['Foo-Bar-abc'], true); assert.equal(actual, 'Newfoo-newbar'); <ins> replacePattern = parseReplaceString('newfoo-newbar'); actual = replacePattern.buildReplaceString(['foo-Bar'], true); assert.equal(actual, 'newfoo-Newbar'); replacePattern = parseReplaceString('newfoo-newbar'); actual = replacePattern.buildReplaceString(['foo-BAR'], true); assert.equal(actual, 'newfoo-NEWBAR'); </ins> replacePattern = parseReplaceString('newfoo_newbar'); actual = replacePattern.buildReplaceString(['Foo_Bar'], true); assert.equal(actual, 'Newfoo_Newbar');

Discussion:
, Replace string functionality in search does not work properly for hyphen and underscore separated variables , Initially figured it out from this Example: Replacingto with preserve case turned on replaces correctly to Replacing to with preserve case turned on replaces incorrectly to instead of PS : Additional Info from the code I found out there is a bug in function. The whole idea to call the replacement function again at was to reuse the already existing replacement logic ( First char capital , full caps and full small) but there was a bug as the hyphens and underscores were not even called because of wrong ordering in the condition checking logic.
Thanks for the PR, can you please phrase this issue in the form of a bug report (ie describe what to do, what happens, what is supposed to happen)
Change:
"prefix": "forin", "body": [ "for (const ${1:key} in ${2:object}) {", <del> "tif (${2:object}.hasOwnProperty(${1:key})) {", </del> <ins> "tif (Object.prototype.hasOwnProperty.call(${2:object}, ${1:key})) {", </ins> "ttconst ${3:element} = ${2:object}[${1:key}];", "tt$0", "t}",

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.35.0 OS Version: OSX 10.15.5 Steps to Reproduce: the 'forin' code snippet. Watch as hasOwnProperty is employed. eslint with eslint:recommended and watch the lint tool fail. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Change:
this._stickyScrollVisibleContextKey = EditorContextKeys.stickyScrollVisible.bindTo(this._contextKeyService); const focusTracker = this._register(dom.trackFocus(this._stickyScrollWidget.getDomNode())); this._register(focusTracker.onDidBlur(_ => { <del> this._disposeFocusStickyScrollStore(); </del> <ins> const height = this._stickyScrollWidget.getDomNode().clientHeight; if (height !== 0) { this._disposeFocusStickyScrollStore(); } else { // If the height is 0, then the blur has been caused by scrolling. In that case keep the focus on the sticky scroll. this._focusedStickyElementIndex = -1; this.focus(); } </ins> })); this._register(focusTracker.onDidFocus(_ => { this.focus();

Discussion:
Testing have a couple of lines in sticky scroll Focus sticky scroll scroll inside the file to a place that sticky scroll lines disappear scroll to a place that has sticky scroll lines again Observe: focus is lost. I would have expected that focus is kept.
Closing the issue since this is actually by design. Still I would have expected otherwise.
I am actually reopening it since I think the behavior is not good when scrolling using the scroll bar / minimap
Do the following: focus sticky scroll use the minimap to scroll to the top of the file whithout releasing the mouse Observe: sticky scroll disappears and focus is gone Scroll into the file again Observe: sticky scroll apprears without focus. I would have expected in this case that the focus is preserved since I never released the mouse button.
For the person who will be doing the verification, a regression has been found relating to the incorrect focusing of the sticky scroll which has already been fixed in the following PR: You may track its release through the corresponding issue: Please test once the other PR is released on insiders. In the meantime the label unreleased will be . Alternatively test on Code OSS.
Change:
private contextService: IWorkspaceContextService, private environmentService: IWorkbenchEnvironmentService, private outputChannelId: string, <del> taskSystemInfoResolver: TaskSystemInfoResovler </del> <ins> private readonly configurationService: IConfigurationService, taskSystemInfoResolver: TaskSystemInfoResovler, </ins> ) { this.activeTasks = Object.create(null);

Discussion:
Steps to reproduce: clone open a terminal Debug viewlet Launch client Observe that building never finishes Now switch the terminal to the npm: watch task Observe: building finished. Looks like the terminal is not delivering any output as long as the view is not visible.
are there any differences on when onLineData occurs in the terminal with conpty?
discovered a new issue
Change:
return undefined; } <ins> private async getUpstreamBranch(branch: Branch): Promise<Branch | undefined> { if (!branch.upstream) { return undefined; } try { const upstreamBranch = await this.getBranch(`refs/remotes/${branch.upstream.remote}/${branch.upstream.name}`); return upstreamBranch; } catch (err) { this.logger.warn(`Failed to get branch details for 'refs/remotes/${branch.upstream.remote}/${branch.upstream.name}': ${err.message}.`); return undefined; } } </ins> async getRefs(query: RefQuery = {}, cancellationToken?: CancellationToken): Promise<Ref[]> { const config = workspace.getConfiguration('git'); let defaultSort = config.get<'alphabetically' | 'committerdate'>('branchSortOrder');

Discussion:
Testing Start from , on a repo: The git extension will associate as the most likely candidate for 's base. But since does have an upstream, , which, at the point was created, was pointing to the same commit as itself... wouldn't be a better base candidate instead?
I think that this makes sense to me however would you favour the remote branch (origin/foo) just because it points to the same commit as when was created or should it be a general rule that if a remote is present, we would favour it?
Will mark this and look out for additional feedback.
Though more about this and since we are adding and actions to the incoming node, it does make sense for it to be an upstream branch. Marking the issue as "bug" so that it gets verified during endgame.
Change:
<ins> name: Bad Tag on: create jobs: main: runs-on: ubuntu-latest if: github.event.ref == '1.999.0' steps: - name: Checkout Actions uses: actions/checkout@v2 with: repository: "microsoft/vscode-github-triage-actions" ref: stable path: ./actions - name: Install Actions run: npm install --production --prefix ./actions - name: Run Bad Tag uses: ./actions/tag-alert with: token: ${{secrets.VSCODE_ISSUE_TRIAGE_BOT_PAT}} tag-name: '1.999.0' </ins>

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --<!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Same issue as , the tag is being to the repository again. Breaking automated tools like Renovate Bot thinking that there is a new version to update. <img width="934" alt="image" src="https://user-"
Is there a way a GitHub action could help identify who pushed the tag and delete the tag automatically? /cc
We can id the tag and ping the creator, we don't give our Actions git write access so can't go and delete the tag automatically.
Deleted tag manually, action to ping the pusher upon pushing it back to the repo.
Change:
category: CHAT_CATEGORY, keybinding: { weight: KeybindingWeight.WorkbenchContrib, <del> primary: KeyMod.CtrlCmd | KeyMod.Shift | KeyCode.KeyI </del> <ins> primary: KeyMod.CtrlCmd | KeyMod.Shift | KeyCode.KeyI, linux: { primary: KeyMod.CtrlCmd | KeyMod.Shift | KeyMod.Alt | KeyCode.KeyI } </ins> } }); }

Discussion:
VS Code Version: 1.80.0-insider OS Version: Ubuntu 22.04 ctrl + shift + I is the default shortcut for formatting a document.
Today we have: for Inline Chat or for showing the Chat View for the Quick Question experience (I liked it because it aligns with Cmd/Ctrl+Shift+P) Options: Use a different keybinding for Quick Question (any ideas :sweat_smile: ) Add an in for only Linux () to open Quick Question Something else? To unblock I'll go with Option 2.
Change:
if (walkthroughID) { const selectedCategory = typeof walkthroughID === 'string' ? walkthroughID : walkthroughID.category; <del> const selectedStep = typeof walkthroughID === 'string' ? undefined : walkthroughID.step; </del> <ins> const selectedStep = typeof walkthroughID === 'string' ? undefined : walkthroughID.category + '#' + walkthroughID.step; </ins> // We're trying to open the welcome page from the Help menu if (!selectedCategory && !selectedStep) {

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.85.2 OS Version: MacOS ventura 13.4.1 According to it appears that I should be able to execute the command: or This should open up a specific step of my extension's walkthrough. However whenever I include my I am getting this error when executing the command: <img width="1050" alt="image" src=""As a side note, not including a step id is working just fine, however I would like to be able to open a specific step for this case.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.86.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
I don't believe we ever supported this args format for opening a walkthrough step. You can try this instead: vscode.commands.executeCommand('', { category: 'extensionId#walkthroughId', step: 'stepId' }, false);
Tried this and it will open the walkthrough, however it will not open the step that is specified.
Could you please share the code snippet you used to execute this command?
here it is! (sorry for the delay) EDIT: this may be related or not but throughout tesing with this snippet I somehow managed to get two welcome pages at once in the editor <img width="264" alt="image" src=""
vscode.commands.executeCommand('', , false);
! !
Change:
assert.deepStrictEqual(actual[0].keybindingMatches!.firstPart, { keyCode: true }); }); <ins> test('filter exact matches also return chords', async () => { const command = 'a' + uuid.generateUuid(); const expected = aResolvedKeybindingItem({ command, firstChord: { keyCode: KeyCode.KeyK, modifiers: { ctrlKey: true } }, secondChord: { keyCode: KeyCode.KeyC, modifiers: { ctrlKey: true } }, when: 'whenContext1 && whenContext2', isDefault: false }); prepareKeybindingService(expected, aResolvedKeybindingItem({ command, firstChord: { keyCode: KeyCode.Escape, modifiers: { shiftKey: true, metaKey: true } }, secondChord: { keyCode: KeyCode.KeyC, modifiers: { ctrlKey: true } }, when: 'whenContext1 && whenContext2', isDefault: false })); await testObject.resolve(new Map<string, string>()); const actual = testObject.fetch('"control+k"').filter(element => element.keybindingItem.command === command); assert.strictEqual(1, actual.length); assert.deepStrictEqual(actual[0].keybindingMatches!.firstPart, { ctrlKey: true, keyCode: true }); assert.deepStrictEqual(actual[0].keybindingMatches!.chordPart, {}); }); </ins> test('filter modifiers are not matched when not completely matched (prefix)', async () => { testObject = instantiationService.createInstance(KeybindingsEditorModel, OperatingSystem.Macintosh); const term = `alt.${uuid.generateUuid()}`;

Discussion:
Currently, to find conflicts caused by a chord, you need to search for the first sequence, without any quotes. This works, but since the search is global across all four columns of information for each keyboard rule, it brings up a variety of commands that you're not interested in. Additionally, it's probably not an obvious way to find conflicts for most VSCode users. I wonder if "Show Same Keybindings" should not only show the exact same keybindings, but also any keybindings where the first sequence of a chord matches. Alternatively, there could be a second option to the context menu that does this.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.466 --<!-- potentialduplicatescomment --
I like the idea of having separate entry/mechanism to look for keybindings containing keys.
Similarly, when editing a keybinding through the keybinding edit widget, when it warns you with "x existing commands have this keybinding", it should probably also warn you if that keybinding is not a chord, but it appears in an existing chord sequence, which again, has the potential for conflicts. With the two options being that those chord conflicts are either to the existing warning count, or an additional warning is with its own count.
Definitely. Some sort of mode (or at least an obvious switch) to search for first strokes in a chord would be amazing.
great
To verify: Enable Record Keys option in the Keyboard Shortcuts editor available in the search box Type Make sure all commands with cmd+k chord are shown. If you have a command with exact cmd+k keybinding, that shall also be shown.
Change:
} } <del> type Root = null | undefined; </del> <ins> type Root = null | undefined | void; </ins> type TreeData<T> = { message: boolean, element: T | Root | false }; interface TreeNode extends IDisposable {

Discussion:
Issue Type: <bBug</bWith the change from , the data fired from an event emitter is no longer optional. For extensions using the API, firing an emitter for without any arguments is now a compilation error. We should add to the type list here. VS Code version: Code - Insiders 1.45.0-insider (, 2020-05-04T09:21:17.770Z) OS version: Darwin x64 18.7.0 <!-- generated by issue reporter --
Hi, has this been implemented? I am on VSCode 1.45.1 and I still get this error when trying to compile. !
Yes, but the EventEmitter still needs to be defined with type ,
Change:
if (insertion && model && lineCount > this._xterm.raw.rows) { const lineNumber = lineCount + 1; model.pushEditOperations(null, [{ <del> range: { startLineNumber: lineNumber, endLineNumber: lineNumber, startColumn: 1, endColumn: 1 }, text: this._getContent(true) </del> <ins> range: { startLineNumber: lineNumber, endLineNumber: lineNumber, startColumn: 1, endColumn: 1 }, text: this._getContent(1) </ins> }], () => []); } else { model = await this._getTextModel(this._instance.resource.with({ fragment: this._getContent() }));

Discussion:
Using here, I cannot enter the accessible buffer https://user-
The issue is that here, the default tab behavior is to focus the terminal tabs element edit: hard to repro, that's not the cause
ok this happens when is not applied to . See here that the buffer editor does get focused here, but you cannot see it https://user-
Repro: run some commands - - - Try to wasn't applied to so the accessible buffer isn't visible
https://user-

Currently when you use navigate accessible buffer you get a quick pick with the options, I expected changing these to scroll to the position without accepting it, and escape to revert to the original scroll position.
As part of this, providing ~1/3 of the viewport of context above would also be good
We'd need to think about how we to communicate the preview information to a screen reader user, as a pre"view" is usually visual
I don't think making this available to the screen reader makes sense, it would just complicate navigating the list. It is useful for sighted users though.
Oh I understand now - you mean on change of the active quick pick item, reveal the line and on enter, focus that line (as it already does)
Yep
To verify, in a terminal with shell integration, run some commands. to enter the accessible buffer. to . Without pressing , use the arrow keys to go between the options. It should scroll to the command if it is outside of the viewport.
Works but I opened
Change:
if (ref === '~') { const fileUri = Uri.file(path); const uriString = fileUri.toString(); <del> const [indexStatus] = repository.indexGroup.resourceStates.filter(r => r.original.toString() === uriString); </del> <ins> const [indexStatus] = repository.indexGroup.resourceStates.filter(r => r.resourceUri.toString() === uriString); </ins> ref = indexStatus ? '' : 'HEAD'; }

Discussion:
I admit that it's a niche scenario, but I think that what "Open Changes" shows for not-yet-staged changes to files that have been detected as renamed in the index is incorrect, at least inconsistent with how changes to files in the index are shown that have not been renamed. Steps to Reproduce: an empty directory and initialize a git repository in it. that directory create two files and with identical content: This exact content is somewhat important, as I've confirmed that it triggers git's "rename detection" (checked with git v2.14.1). and commit both files. the first line in both files. to . "": ! does the right thing for both files, that is, it shows the changes between HEAD and the staged version: : ! : ! the first line in both files once more, but don't stage these changes. still shows the right thing for (in this case the changes between the staged version and the file in the working tree): ! As the content of both files is identical both in the index and the working tree, I would have expected the exact same result for , but now the left side is just empty instead of showing the staged version: ! VSCode Version: Code 1.16.1 (, 2017-09-14T16:26:20.018Z) OS Version: Linux x64 4.12.13-1-ARCH
Hehe great catch! Would you like to to it?
So is this issue still open and up for grabs? If so I would like to try to help
Just look above your comment, there's a PR for it already:
Fixed by