jiebi/CodeConvo huggingface dataset:
Change:
const index = input.items.indexOf(event.item); if (index !== -1) { const items = input.items.slice(); <del> items.splice(index, 1); </del> <ins> const removed = items.splice(index, 1); const activeItems = input.activeItems.filter((ai) => ai !== removed[0]); </ins> input.items = items; <ins> if (activeItems) { input.activeItems = activeItems; } </ins> } } })),

Discussion:
Repro: recently opened down x on one of the entries The view will be scrolled to the top, making it much more difficult than it needs to be to clean out entries you no longer want in recently opened.
Could be the picker widget behaviour, not sure. Does it have API to remove items individually? //cc
Yeah I call  Leaving it up to if this is a bug or not.
verification steps: Trigger recently opened Scroll down Press x on one of the entries (not the highlighted one) The cursor should stay put.
Still seeing this
Ah... I fixed the issue on the active item persisting but not the scroll.
duping this to as we will fix this generically.
Change:
import { IProductService } from 'vs/platform/product/common/productService'; import { registerIcon } from 'vs/platform/theme/common/iconRegistry'; import { defaultButtonStyles, defaultInputBoxStyles } from 'vs/platform/theme/browser/defaultStyles'; <del> import { isMacintosh } from 'vs/base/common/platform'; </del> <ins> import { isMacintosh, isWindows } from 'vs/base/common/platform'; </ins> import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding'; import { ResolvedKeybinding } from 'vs/base/common/keybindings';

Discussion:
Drive letter on Windows are uppsercase: <img width="393" alt="image" src="https://user-"
we are not using the label service for the path portion because the path needs to be editable by the user. i.e. They should be able to edit the string directly and we should be able save that into our list. In the local case, the default behavior is to use the file picker, but if you are editing a remote path that you are not connected to, you need to be able to edit the string. I consider this change but I'm a little nervous that we might get some UI representation that is not safe for editing. <img width="720" alt="image" src="https://user-"
Fair, we have methods to only fix the drive letter casing, so maybe safer to just do that.
I believe I solved this a part of a separate issue.
Assigning to Jan for verification
I still see lowercase drive letters: <img width="613" alt="image" src="https://user-"
Change:
// DA events private readonly _onDidExitAdapter = new Emitter<AdapterEndEvent>(); private debugAdapter: IDebugAdapter | null; <ins> private stoppedSinceLastStep = false; </ins> private toDispose: IDisposable[] = [];

Discussion:
Stepping using the debug adapter that I helped develop has been broken by a VS Code change between 1.78.2 and 1.79.0. I used a to log the messages sent back and forth using the same extension version, but different VS Code versions. I attached the logs below. After diffing the two files, the only difference is that the "scopes" request isn't sent to the adapter after the "next" request reports a stopped event. The end result is that the debugging UI in VS Code is stuck in "running" mode even though the debug adapter is stopped, and the user has no way to advance. See
I think this is related to the fact that you send the "stopped" event before the "next" response. We should be able to support that but as a workaround you could respond to "next" before stopping the debugger.
Thanks for the quick response I will look into that workaround. In what cases is tit required? Any type of step?
I see the issue but it will be too much of a risky change to get into our next stable release. I will try to address it in July but I'd recommend working around it in your extension.
I understand. I implemented the workaround in my extension and initial tests show that it works, so thanks for making me aware of that.
For my own reference, I think it should be ok to do immediately instead of waiting for the response.
Hi what are some verification steps for this issue?
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
I verified this by hacking mock-debug, but are you able to verify the change in Insiders, or have you moved on to not rely on that behavior anymore?
I've modified my extension to implement your workaround. I can download an old version of the extension to test this if you want.
It's ok, I think I've got it now
Change:
posix: null }; <ins> const posixCwd = (() => { if (platformIsWin32) { // Converts Windows' backslash path separators to POSIX forward slashes // and truncates any drive indicator const regexp = //g; return () => { const cwd = process.cwd().replace(regexp, '/'); return cwd.slice(cwd.indexOf('/')); }; } // We're already on POSIX, no need for any transformations return () => process.cwd(); })(); </ins> export const posix: IPath = { // path.resolve([from ...], to) resolve(...pathSegments: string[]): string {

Discussion:
We will ship Electron with to stable soon so we should also look into bringing our copy of library to the same version. Checking for the diff, it seems to be a few commits after and up until //cc
Hm, the first change is already pretty bad for us: Because it seems to depend on a new thing which is maybe defined globally and probably optimised / cached / snapshotted. Maybe we should rather look out for actual bug fixes and focus on those... Changes: I think only the 2 fix commits stand out from the others
I assume you skipped over right?
Reopening given unit test failures, I had to revert the change for now.
yes I skipped the primordials. I didn't dig into why they do this, but it seemed easy enough to just call the string functions instead. As for the test failures, new PR
Primordials are only meant for Nodejs internal code usage, external users should just replace them with corresponding JavaScript builtins. You can read more about why Nodejs does it
Change:
*--------------------------------------------------------------------------------------------*/ import { IContextMenuDelegate } from 'vs/base/browser/contextmenu'; <del> import { $, addDisposableListener, EventType, isHTMLElement } from 'vs/base/browser/dom'; </del> <ins> import { $, addDisposableListener, EventType, getActiveElement, isAncestor, isHTMLElement } from 'vs/base/browser/dom'; </ins> import { StandardMouseEvent } from 'vs/base/browser/mouseEvent'; import { Menu } from 'vs/base/browser/ui/menu/menu'; import { ActionRunner, IRunEvent, WorkbenchActionExecutedClassification, WorkbenchActionExecutedEvent } from 'vs/base/common/actions'; import { isCancellationError } from 'vs/base/common/errors'; <del> import { combinedDisposable, DisposableStore } from 'vs/base/common/lifecycle'; </del> <ins> import { combinedDisposable, DisposableStore, IDisposable } from 'vs/base/common/lifecycle'; </ins> import { IContextViewService } from 'vs/platform/contextview/browser/contextView'; import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding'; import { INotificationService } from 'vs/platform/notification/common/notification';

Discussion:
click to open context menu in text editor +P to open quick open :bug: both context menu and quick open are dismissed !
re: context menu
This is not a regression so assigning to december
I'm going to pass to you for your take. Here's what I found out. When we show the command palette that causes the editor context menu to trigger the hide: This hide, focuses the editor... but in doing so, that causes the Quick Pick's didBlur to hide: which will hide the quick pick if is set to which is the default. This behavior with context menus seems to repro: Always in context menus of the editor Only with custom menus (not native menus) in the rest of the product (tree views, Account/Gear menu, etc)
Two actions here: needs to be removed or handled better (passing that to or menus should follow the logic: if ESC/selection, focus what was previously focused. If dismissed due to focus lost, don't restore focus (this goes to
my suspicion is that the editor contribution is old and unnecessary as the behavior is built-in to the menu widget. Removing it, we can centralize the logic to the menu widget.
re-opening as we still have some work to do on the custom menu side
Change:
} }); <del> const mtw: MainThreadWorkspace = instantiationService.createInstance(<any>MainThreadWorkspace, SingleProxyRPCProtocol({ $initializeWorkspace: () => { } })); </del> <ins> const mtw = instantiationService.createInstance(MainThreadWorkspace, SingleProxyRPCProtocol({ $initializeWorkspace: () => { } })); </ins> return mtw.$startFileSearch('', null, false, 10, new CancellationTokenSource().token); });

Discussion:
Due to an oversight, does not enforce arguments or its return type. Fixing this exposes around 80 typings errors in our codebase that should be addressed To fix this issue in your code: , comment out the . (Do not check in this change. I will check in the change to the signature once all error have been fixed) look at the file assigned to you and fix the type error (you may need to restart the compile since we are changing such a core type) [x] — [x] — [x] — [x] — [x] — [x] — [x] — [ ] — [ ] — [ ] — [ ] — [x] — [x] — [x] — [x] — [x] — [x] — [ ] — [x] —
Change:
<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ export default fetch; </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. --Does this issue occur when all extensions are disabled?: Yes/No No. The issue occurs in a built-in extension so extensions need to be enabled to see the issue. <!-- 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. --Version: 1.93.0-insider (Universal) Commit: Date: 2024-08-26T05:04:02.640Z Electron: 30.3.1 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0 Steps to Reproduce: VS Code behind a proxy server and make a call to the function from the package included with VS Code similar to the one below. After the changes listed in , we began seeing failures from the Microsoft Authentication extension with the following log entries at startup. We rely on that extension to allow another extension we developed internally to authenticate our users. After debugging into the extension source, I found that the issue was originating here. After reading through the previously mentioned pull request, I figured that the call was hanging because the new function was not handling proxy configurations the same way (a common issue in corporate settings). I pulled down VS Code, built from source and tested a change that resolves the issue. I'd like to open a pull request with the fix if you agree that there is a bug in this flow. System Information
will be exploring fixing this type of issue transparently.
This will be in Monday's Insiders build. Can you please give that a try when it drops so we know for a fact we've fixed the issue for you?
that fixed the issue. Thanks so much for the quick response to our problem!
Change:
"./vs/platform/contextview/browser/contextMenuService.ts", "./vs/platform/contextview/browser/contextView.ts", "./vs/platform/contextview/browser/contextViewService.ts", <del> "./vs/platform/credentials/test/node/keytar.test.ts", </del> "./vs/platform/diagnostics/electron-main/diagnosticsService.ts", "./vs/platform/dialogs/common/dialogs.ts", "./vs/platform/dialogs/node/dialogIpc.ts",

Discussion:
What is the purpose of in vs/platform? should only be used for shared services across processes. Please move it elsewhere, e.g. .
Change:
const groupChildren = <SettingsTreeGroupElement[]>model.children.filter(c => c instanceof SettingsTreeGroupElement); const groupsIt = Iterator.fromArray(groupChildren); return Iterator.map(groupsIt, g => { <del> let nodeExists = true; try { tree.getNode(g); } catch (e) { nodeExists = false; } </del> const hasGroupChildren = g.children.some(c => c instanceof SettingsTreeGroupElement); return { element: g, <del> collapsed: nodeExists ? undefined : true, </del> <ins> collapsed: undefined, </ins> collapsible: hasGroupChildren, children: g instanceof SettingsTreeGroupElement ? createTOCIterator(g, tree) :

Discussion:
Issue Type: <bBug</bTesting Repo settings editor to the section click to switch to instead of Bug TOC is collapsed. Any scrolling causes the TOC to be expanded at the correctly again VS Code version: Code - Insiders 1.31.0-insider (, 2019-01-29T06:13:57.866Z) OS version: Darwin x64 18.2.0 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Probably another case of The TOC tree sometimes maintains its selection/expansion state, sometimes not.
Hey should expansion state be preserved using the string identity? was for focus/selection, this is for expansion state.
Adding myself so I don't forget about this.
Let's merge this early June:
Thanks
Change:
} if (resource) { <del> uri = resource.resourceUri; </del> <ins> uris = [...resourceStates.map(r => r.resourceUri), resource.resourceUri]; </ins> } } <del> if (!uri) { </del> <ins> if (!uris) { </ins> return; } <del> const activeTextEditor = window.activeTextEditor && window.activeTextEditor; const isSameUri = activeTextEditor && activeTextEditor.document.uri.toString() === uri.toString(); const selections = activeTextEditor && activeTextEditor.selections; const viewColumn = activeTextEditor && activeTextEditor.viewColumn || ViewColumn.One; await commands.executeCommand<void>('vscode.open', uri, viewColumn); if (isSameUri && selections && window.activeTextEditor) { window.activeTextEditor.selections = selections; </del> <ins> const preview = uris.length === 1 ? true : false; const activeTextEditor = window.activeTextEditor; for (const uri of uris) { // If the active editor matches the current uri, get its selection const selections = activeTextEditor && activeTextEditor.document.uri.toString() === uri.toString() ? activeTextEditor.selections : undefined; const opts: TextDocumentShowOptions = { preserveFocus: true, preview: preview, viewColumn: activeTextEditor && activeTextEditor.viewColumn || ViewColumn.One }; const document = await workspace.openTextDocument(uri); await window.showTextDocument(document, opts); if (selections && window.activeTextEditor) { window.activeTextEditor.selections = selections; } </ins> } }

Discussion:
VSCode Version: Code - Insiders 1.13.0-insider (, 2017-05-26T05:14:23.944Z) OS Version: Windows_NT ia32 10.0. Currently you can multi-select items in the Git files view and if you right-click, the & menu items will only open the file/change of the focused item, with the stage/unstage command work with the whole selection. It would be great to have these 2 command act upon the whole selection.
Change:
import { localize } from 'vs/nls'; import * as DOM from 'vs/base/browser/dom'; <del> import * as network from 'vs/base/common/network'; </del> import { Event } from 'vs/base/common/event'; import { ITableContextMenuEvent, ITableEvent, ITableRenderer, ITableVirtualDelegate } from 'vs/base/browser/ui/table/table'; import { Disposable } from 'vs/base/common/lifecycle';

Discussion:
Testing <img width="1617" alt="image" src="https://user-"
I can't get squiggles to show up for the commit input box at all, even after following the steps from the linked TPI. What are some steps to verify this, or maybe someone else can verify?
Thanks Reopening the bug as the fix for this has introduced a regression.
Checked in a better fix for this issue. Should be included in tomorrow's Insiders release (2022-08-26).
closedWith
Verified, but the actions in the hover don't do anything: !
Thanks I have filed to track the issue with the actions.
Change:
padding: 10px; border-radius: 5px; cursor: pointer; <del> } </del>  No newline at end of file <ins> } </ins>

Discussion:
Issue Type: <bBug</bI believe this just started, but I can no longer resize the split editor via the middle bar. Diff editor still works, and it works fine in stable as well. VS Code version: Code - Insiders 1.39.0-insider (, 2019-09-09T17:00:17.505Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Not sure which editor you mean... what steps are you doing to get to that UI?
From the command palette, Preferences: Open Settings (JSON) !
does that provide what you need?
For some reason I no longer can open that view... it always opens a regular editor, not that old settings editor.
now you have to set . I can reproduce but haven't changed it,
Aha! Couldn't find the name of that setting...
Since I investigated it I ended up just making a fix for it. Not sure why it broke tho.
Change:
import { localize } from 'vs/nls'; import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; <del> import { IProductService } from 'vs/platform/product/common/productService'; </del> import { Registry } from 'vs/platform/registry/common/platform'; import { inputPlaceholderForeground } from 'vs/platform/theme/common/colorRegistry'; import { IThemeService } from 'vs/platform/theme/common/themeService';

Discussion:
We still have the check in place to disable these in the stable build...
Can be verified by code review, or once we have a stable build.
Verifying on 0.11.1 Edit: I see the suggestion is enabled, but the behaviour is off to me. Discussing offline. Edit 2: Discussed. Marking as verified.
Change:
} public defines(colorId: ColorIdentifier): boolean { <del> return this.customColorMap.hasOwnProperty(colorId) || this.colorMap.hasOwnProperty(colorId); </del> <ins> const customColor = this.customColorMap[colorId]; if (customColor instanceof Color) { return true; } return customColor === undefined /* !== DEFAULT_COLOR_CONFIG_VALUE */ && this.colorMap.hasOwnProperty(colorId); </ins> } public setCustomizations(settings: ThemeConfiguration) {

Discussion:
From Add to setting See that the editor background changes to the 'default' gray color Comment or delete the setting The background color doesn't change back to the theme color, and I can't make it go back until reloading the window
Change:
} else { this._onDidChangeViewWelcomeState.fire(); } <del> if (!this._terminalService.activeInstance?.shellLaunchConfig.extHostTerminalId) { // showPanel is already called with !preserveFocus // when extension host terminals are created this._terminalGroupService.showPanel(true); } </del> <ins> // we don't know here whether or not it should be focused, so // defer focusing the panel to the focus() call // to prevent overriding preserveFocus for extensions this._terminalGroupService.showPanel(false); </ins> if (hadTerminals) { this._terminalGroupService.activeGroup?.setVisible(visible); }

Discussion:
According to the documentation, if calling show(true), the terminal will be made visible but it won't capture the keyboard focus. I also remember in the past this worked. For some months already I noticed that regardless of how I call show, the focus is always taken. Anything changed? Is there already an issue that you tracking for this? Am I doing anything wrong? Related to this, if we won't manage to fix this behavior, how can we make key bindings for commands to be recognized even when the terminal has the focus? For example, when having focus in the terminal, if I press F5 debugging will start. The terminal will not try to write something for "F5". But if I run another key combination that I defined for some extension command, the terminal will react to the key combination (will try to write something) and the command will not be triggered (unless focus is somewhere else). We have this issue in the CMake Tools repository and the user would be happy if we fix this problem either way.
Hey, I would like to work on this issue. Could you give me any pointers? Where should I start?
this one's a little involved as it needs an extension to trigger the issue, you'd be better off finding an issue with the help wanted label.
Okay, thanks!
Tried this in an extension after making sure I had a terminal open: And the focus moved into the terminal.
did you have focus in the terminal before running that? preserve focus returns the focus to whatever was focused before. I'm unable to reproduce the problem using the exact code you mention above. Could you please include a gif? !
!
Change:
return hash; } <del> export function getPermalink(gitAPI: GitAPI, useSelection: boolean, hostPrefix?: string): string | undefined { </del> <ins> export function getLink(gitAPI: GitAPI, useSelection: boolean, hostPrefix?: string, linkType: 'permalink' | 'headlink' = 'permalink'): string | undefined { </ins> hostPrefix = hostPrefix ?? 'https://github.com'; const fileAndPosition = getFileAndPosition(); if (!fileAndPosition) {

Discussion:
a desktop clone open with some uncommitted changes Continue Edit Session open on :bug: edit session is not applied The reason for this is that we are opening a permalink instead of preserving the current branch checkout so the edit session identifier doesn't match up and the edit session doesn't get applied. This used to work and regressed with the edit session identifier API work, which applies stricter checks to edit session identities. Thanks for finding this in !
not seeing a command
sorry, that should have been , not
Change:
const markdown = new MarkdownString('', true) .appendMarkdown(reason) .appendText(' ') <del> .appendLink(uri, adjustSettings); </del> <ins> .appendLink(uri, adjustSettings, configureUnicodeHighlightOptionsStr); </ins> result.push(new MarkdownHover(this, d.range, [markdown], false, index++)); } return result;

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?: Yes/No When I hover over the command in the Unicode Highlighted character I get a very long tooltip message (most of it isn't in the demo): ! Version: 1.64.0-insider (user setup) Commit: Date: 2022-01-21T13:25:29.978Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0.