jiebi/CodeConvo huggingface dataset:
Code change:
override async run(accessor: ServicesAccessor): Promise<void> { const nativeHostService = accessor.get(INativeHostService); <ins> const window = getActiveWindow(); if (isAuxiliaryWindow(window)) { return nativeHostService.closeWindowById(await window.vscodeWindowId); } </ins> return nativeHostService.closeWindow(); } }

Related discussion:
text: <!-- 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 <!-- 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: OS Version: Version: 1.84.0-insider (user setup) Commit: Date: 2023-10-23T05:34:05.496Z Electron: 25.9.1 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: two workspaces a couple of files Active Editor into a New Window on the new window and Press Alt+F4 : aux window closes. Actual: VS Code closes the workspace and both windows associated with it.
Can you see if is assigned as keybinding? I assume this goes through our global window close handler that has not yet adopted aux windows.
I have default keybindings { "key": "alt+f4", "command": "" },
Code change:
.panel > .title .monaco-action-bar .action-item.viewpane-filter-container { max-width: 400px; <del> min-width: 300px; </del> <ins> min-width: 150px; </ins> margin-right: 10px; }

Related discussion:
text: Issue Type: <bBug</bthe integrated console viewlets to a vertical layout the viewlet narrow When wide enough: ! Once narrowed: ! Expected result: Debug Console search bar shrinks/hides itself in order to show other tabs first (like in the first screenshot). The 3 dots "works", but is, at least in my opinion, more annoying than not being able to search in the Debug Console when the viewlet is narrow. VS Code version: Code 1.63.2 (, 2021-12-15T09:40:02.816Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<!-- generated by issue reporter --
The min width is 300, I think that can be narrower. The problems view filter input goes into the body when the view is too narrow, which is sorta cool <img width="571" alt="image" src="https://user-"but I won't implement that right now
Actually it was easy to opt into that. I tweaked the min widths and also when the pane is narrow, the filter box will move down into the body
Holy, I forgot about this issue! Love the idea of copying the behaviour of the Problems tab! Excited to try it on Insiders :) Thanks !
Code change:
['.xhtml', 'application/xhtml+xml'], ['.oft', 'font/otf'], ['.xml', 'application/xml'], <ins> ['.wasm', 'application/wasm'], </ins> ]); export function getWebviewContentMimeType(resource: URI): string {

Related discussion:
text: To load local resources (for example ones bundled with an extension), the  method must be used. As far as I can tell, when a URI produced in this way is requested by a webview, VSCode serves it via something like a local webserver. But there is no way to configure the MIME type that the URI gets served with. This request is to add a way to set the MIME type. This is important for extensions which want to load WebAssembly resources in the webview. The most efficient method to do so is , but this only works if the WASM blob is served as . So currently it doesn't seem possible to load WASM in a webview in this way. Since fallback methods may fail to cache WASM compilation results, I've measured that for a large WASM blob it's actually more efficient to load it from the internet via , as then subsequent loads reuse WASM compilation results, than it is to load it from a local resource.
/verified
Code change:
} } <del> return undefined; </del> <ins> return null; </ins> } private hasSelectedMarkerFor(resource: ResourceMarkers): boolean {

Related discussion:
text: Testing Not sure if this lack of functionality blocks anything truly useful, but at least in the treeview, you can multi-select problems and copy them to the clipboard. In the table view you can't.
This also has the side effect of losing a multi-select that you may have had in the treeview.
what was the thinking for enabling multi-select in the problems treeview? Was there a particular scenario or this is what the default behaviour is for a treeview? If there is a real scenario, than we should enable multi-select in the table as well.
You can copy multiple problems is the primary use case.
that makes sense. Thanks!
Code change:
if (!resolveResult.bubble) { shouldPreventDefault = true; } <ins> this._log(`+ Invoking command ${resolveResult.commandId}.`); </ins> if (typeof resolveResult.commandArgs === 'undefined') { this._commandService.executeCommand(resolveResult.commandId).then(undefined, err => this._notificationService.warn(err)); } else {

Related discussion:
text: Issue Type: <bBug</bI remapped command to [Alt + V]. And such keybinding doesn't work. KeybindingService log is as follows. Keybinding seems to pass through vscode to terminal since when I run in terminal it registers keypresses. VS Code version: Code 1.67.2 (, 2022-05-17T18:23:40.286Z) OS version: Linux x64 5.15.41-1-MANJARO Restricted Mode: No Remote OS version: Linux x64 4.19.119-30.2 <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This is working fine for me, I do see the warning that I don't understand though. any insights into what could be happening here? Could the soft dispatch teh terminal does be causing problems with this ignore single modifier thing?
Yes, I think is not dispatched through the keybinding service in this case. Looking again at the OP log: And comparing it with the output I see when binding to : Notice how the OP's log does not contain the keydown event for (i.e. this line ), but there are logs about being dispatched. I think the logs about being dispatched relate to the call the terminal does, but it looks to me that the keybinding service doesn't really get to dispatch the keyboard event, so it doesn't execute the command. I see how is making the log confusing so I will push a change to improve logging to better distinguish between and the real dispatch.
do you have or set in your
Yes I have enabled, but I didn't override . As far as I understand is included in by default.
It is but when is set to true it overrides as a convenience setting for users who use a lot of shell-based keybindings. If you're getting into needing to customize , I'd recommend setting back to false and tweaking instead. I checked the docs and it looks like this is already explained so I don't think there's anything we need to do on our end: !
ok, thanks a lot for your help
Code change:
args.push(`--author="${options.author}"`); } <ins> if (typeof options?.maxParents === 'number') { args.push(`--max-parents=${options.maxParents}`); } </ins> if (options?.refNames) { args.push('--topo-order'); args.push('--decorate=full');

Related discussion:
text: a folder/workspace in VS Code Insiders a git repository in the folder a file, make changes to it, and create multiple commits Expected: commits should appear in the history graph Actual: no commits are being shown in the history graph
this only works when there are multiple commits. I.e. if we has just one commit in the repo, then history isn't displayed. Else works as expected.
Thanks! I have filed to handle the single commit scenario
Code change:
testIds: string[]; } <del> export const isStartControllerTests = (t: ICallProfileRunHandler | IStartControllerTests): t is IStartControllerTests => 'runIn' in t; </del> <ins> export const isStartControllerTests = (t: ICallProfileRunHandler | IStartControllerTests): t is IStartControllerTests => ('runId' as keyof IStartControllerTests) in t; </ins> /** * Request from the main thread to run tests for a single controller.

Related discussion:
text: When I run all tests, the label resets back to after all tests were run. This is very confusing. !
This was a result of a bad filter function that caused all test runs to be treated extension-triggered. The "real" test run would then never have results, or get any output. More importantly, this results in "show test output" usually showing nothing. Taking this as a candidate. Essentially the sequence is: is triggered from the UI, so we prepare TestResults for incoming data and send the TestRunRequest precursor over to the EH EH doesn't associate that request with the existing run calls from its , which gets treated as a brand new run, so we make new TestResults for that run run and states get updated... 's resolves automatically marks the UI-triggered run as complete since the runHandler returned and there are no ongoing TestRuns latest completed TestResults is now the empty one that core created and was never updated so things that use the last result, like "show test output", are empty The code path in is meant to only be taken by the new Continuous Test runs, where the request is long-lived and doesn't have a single associated set of TestResults.
Code change:
async getExtensions(extensionInfos: ReadonlyArray<IExtensionInfo>, arg1: any, arg2?: any): Promise<IGalleryExtension[]> { const options = CancellationToken.isCancellationToken(arg1) ? {} : arg1 as IExtensionQueryOptions; const token = CancellationToken.isCancellationToken(arg1) ? arg1 : arg2 as CancellationToken; <ins> const result = await this.doGetExtensions(extensionInfos, options, token); const uuids = result.map(r => r.identifier.uuid); const extensionInfosByName: IExtensionInfo[] = []; for (const e of extensionInfos) { if (e.uuid && !uuids.includes(e.uuid)) { extensionInfosByName.push({ ...e, uuid: undefined }); } } if (extensionInfosByName.length) { // report telemetry data for additional query this.telemetryService.publicLog2< { count: number }, { owner: 'sandy081'; comment: 'Report the query to the the Marketplace for fetching extensions by name'; readonly count: { classification: 'SystemMetaData'; purpose: 'FeatureInsight'; comment: 'Number of extensions to fetch' }; }>('galleryService:additionalQueryByName', { count: extensionInfosByName.length }); const extensions = await this.doGetExtensions(extensionInfosByName, options, token); result.push(...extensions); } return result; } private async doGetExtensions(extensionInfos: ReadonlyArray<IExtensionInfo>, options: IExtensionQueryOptions, token: CancellationToken): Promise<IGalleryExtension[]> { </ins> const names: string[] = []; const ids: string[] = [], includePreReleases: (IExtensionIdentifier & { includePreRelease: boolean })[] = [], versions: (IExtensionIdentifier & { version: string })[] = []; let isQueryForReleaseVersionFromPreReleaseVersion = true; for (const extensionInfo of extensionInfos) {

Related discussion:
text: This proves that vue version and are indeed not getting properly updated. The root cause of this is the fact the vue extension, unpublished from the Marketplace and published again the same name (thus exposing a bug in the Marketplace) as explained here We still want to help transition your users, and I will go ahead and move this issue to the VS Code repo and Sandeep will investigate next week once he is back from vacation. Thank you !
Update is not detected automatically. It is detected only when user is searching for the extension.
Sorry about this inconvenience caused. Fixed it - We will now detect the update automatically.
<!-- 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 just tested it and confirmed it's fixed in the latest insiders version, thanks a lot!
Adding label based on above comment
Code change:
if (!this._loadEstimator.hasHighLoad()) { // Trash the socket this._lastSocketTimeoutTime = Date.now(); <del> this._onSocketTimeout.fire(undefined); </del> <ins> this._onSocketTimeout.fire({ unacknowledgedMsgCount: this._outgoingUnackMsg.length(), timeSinceOldestUnacknowledgedMsg, timeSinceLastReceivedSomeData }); </ins> return; } }

Related discussion:
text: I've had an SSH window open in the background and noticed that it keeps going through reconnection. Looking at the logs, it looks like vscode is often triggering reconnection, even though nothing strange is going on with my network, as far as I know. Noticed this at home and also the office network. This is the log from vscode. The SSH log doesn't show anything unusual before the resolver is invoked again. Has anything changed here lately?
Sorry this issue fell through the cracks. Are you still running into this?
Yes
Do you perhaps have a log with tracing enabled? The reason in the original log appears to be timeout. That is triggered here -- So the conditions are: a message was written to the socket 20 seconds ago and the server side didn't acknowledge it (and) no data was received from the server within the past 20 seconds (and) no previous timeout event was fired within the past 20 seconds (this just avoid sending many timeout events) (and) the renderer process appears responsive (Just speculating) I think we have fixed something in the terminal land and we now no longer send any data in an idle window. Could it be that your window becomes idle and the connection is dropped by SSH? (I believe due to some terminal heartbeat mechanism there was always data being written every 5 seconds, but now that is no longer happening).
Well, now I can't repro it.
I've more logging via . Please keep an eye out. In case you hit this again, the logging will have more data.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Finally got it
It seems like the log message you touch didn't show up there. But, it does show up in an earlier reconnection in this window (before I enabled trace logging). So I'll just share the full logs This shows a window that was mostly idle with 2 reconnections, the second one had logging at the trace level enabled
Here's my interpretation: the management connection timed out at due to our own timeout logic. We wrote one message and that message didn't get acknowledged within 20s by the server. As an observation, the connection didn't receive any bytes from the server within 320s (5 minutes).
Code change:
if (!this._loadEstimator.hasHighLoad()) { // Trash the socket this._lastSocketTimeoutTime = Date.now(); <del> this._onSocketTimeout.fire(undefined); </del> <ins> this._onSocketTimeout.fire({ unacknowledgedMsgCount: this._outgoingUnackMsg.length(), timeSinceOldestUnacknowledgedMsg, timeSinceLastReceivedSomeData }); </ins> return; } }

Related discussion:
text: this resulted in the core invoking on the SSH extension and the SSH extension replied with a new port i.e. instead of the previous . the extension host connection immediately closed at with code , indicating that perhaps the previous tunnel at was killed as part of invoking . Precisely 20 minutes later, at , both management and extension host connections receive a event from Chromium. I can't quite explain the first timeout, why would the server not acknowledge a message within 20 seconds? But the timing of the second disconnection seems to indicate to me that after 20 min of idleness, the underlying connection is closed. Anyone could be closing it: either on the client side by Chromium or the OS, either on the server side by nodejs or the OS, either by the SSH tunnel timing out. For the second disconnection I think we might need to do something to tackle . For a long time the terminal was doing a heartbeat mechanism which resulted in data being sent over the wire (and that would not make the connection idle), but that was fixed via Right now, if you are really idle in a window, the underlying connection will be idle too and I think the OS or someone closes it as idle after 20 minutes.
My best guess is some other weird optimization where network requests don't even get delivered when an app is in the background. I've noticed this in windows that are not focused
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Code change:
sbomBuildDropPath: $(Agent.BuildDirectory)/vscode-server-win32-$(VSCODE_ARCH) sbomPackageName: "VS Code Windows $(VSCODE_ARCH) Server" sbomPackageVersion: $(Build.SourceVersion) <del> condition: and(succeededOrFailed(), ne(variables['SERVER_PATH'], ''), ne(variables['VSCODE_ARCH'], 'arm64')) </del> <ins> condition: and(succeededOrFailed(), ne(variables['SERVER_PATH'], '')) </ins> displayName: Publish server archive - task: 1ES.PublishPipelineArtifact@1

Related discussion:
text: It appears that this is possible now, and we should consider adopting this in VS Code ()
There is community interest:
Please add this!
Steps for verification: Connect to Windows arm64 using the latest pre-release of SSH extension () Verify that connection is successful Use or similar tool to confirm that executable is of architecture.
Code change:
} widget.focus(focusedItem); <del> const responseContent = isResponseVM(focusedItem) ? focusedItem.response.value : undefined; </del> <ins> const isWelcome = focusedItem instanceof ChatWelcomeMessageModel; let responseContent = isResponseVM(focusedItem) ? focusedItem.response.value : undefined; if (isWelcome) { const welcomeReplyContents = []; for (const content of focusedItem.content) { if (Array.isArray(content)) { welcomeReplyContents.push(...content.map(m => m.message)); } else { welcomeReplyContents.push((content as IMarkdownString).value); } } responseContent = welcomeReplyContents.join('n'); } </ins> if (!responseContent) { return false; }

Related discussion:
text: One way of resolving this would be repeating the position information when I press any of the commands, even if there is no change. Another possibility would be to prevent the widget from refocusing when I am in the first / last element, and I try to move beyond that element. In that way pressing the next command will not produce any feedback if I am in the last one, and the previous will not produce any feedback if I am in the first one. Does it make sense? In any case, this would be a refinement, not something that would prevent someone from using the feature. Originally posted by in
Something else to consider when fine tuning the responses. Right now, position information is announced using an alert in macOS, and a status message in Windows. This is a situation where it makes sense to use an alert in all platforms so that screen readers prioritize this over other events. For example, right now JAWS is announcing position information after reannouncing the widget.
Huh, I'm using for all platforms here which appears to be platform agnostic I think it might just be a JAWS issue - does this repro when using NVDA?
It doesn't, but NVDA handles aria-live differently. You may be right dough. I'll debug NVDA on Monday and we'll know for sure which event it is seeing. JAWS may be simply prioritizing the focus event.
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Focus an accessible view for which there are several elements (like chat responses or notifications). Verify that if you are on the first or last element, pressing next or previous does not result in repeated alerts. it should not notify the screen reader user as nothing has changed.
Note to verifier there's an issue to disable these actions when they cannot be taken, which is the better fix.
Verified. With NVDA, if I press enter on the Next button while on the last chat response, the focus goes back to the response text instead of staying on the button, though that might be by design.
Code change:
private getItemIndexFromEventTarget(target: EventTarget | null): number | undefined { const scrollableElement = this.scrollableElement.getDomNode(); <del> let element: HTMLElement | null = target as (HTMLElement | null); </del> <ins> let element: HTMLElement | SVGElement | null = target as (HTMLElement | SVGElement | null); </ins> <del> while (isHTMLElement(element) && element !== this.rowsContainer && scrollableElement.contains(element)) { </del> <ins> while ((isHTMLElement(element) || isSVGElement(element)) && element !== this.rowsContainer && scrollableElement.contains(element)) { </ins> const rawIndex = element.getAttribute('data-index'); if (rawIndex) {

Related discussion:
text: Testing <img width="290" alt="image" src=""I feel like this context menu should not show up in this case - and in fact, it doesn't if you right click on the commit message to the right... it just repros when you right click on the graph part (the dots, or the lines)
Code change:
<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import * as assert from 'assert'; import 'mocha'; import { ExtensionContext, extensions } from 'vscode'; suite('vscode API - globalState / workspaceState', () => { let extensionContext: ExtensionContext; suiteSetup(async () => { // Trigger extension activation and grab the context as some tests depend on it await extensions.getExtension('vscode.vscode-api-tests')?.activate(); extensionContext = (global as any).testExtensionContext; }); test.only('state', async () => { for (const state of [extensionContext.globalState, extensionContext.workspaceState]) { let keys = state.keys(); assert.strictEqual(keys.length, 0); let res = state.get('state.test.get', 'default'); assert.strictEqual(res, 'default'); await state.update('state.test.get', 'testvalue'); keys = state.keys(); assert.strictEqual(keys.length, 1); assert.strictEqual(keys[0], 'state.test.get'); res = state.get('state.test.get', 'default'); assert.strictEqual(res, 'testvalue'); await state.update('state.test.get', undefined); keys = state.keys(); assert.strictEqual(keys.length, 0); res = state.get('state.test.get', 'default'); assert.strictEqual(res, 'default'); } }); }); </ins>

Related discussion:
text: What you report here seems different to me. Looks like the python extension is calling on something that is not valid JSON? Have you asked the Python extension what this could be?
I see, I'll create a new issue. thanks