jiebi/CodeConvo huggingface dataset:
Code change:
constructor(modulePath: string, args?: string[] | undefined, options?: UtilityProcessOptions); postMessage(channel: string, message: any, transfer?: Electron.MessagePortMain[]): void; kill(signal?: number | string): boolean; <del> on(event: 'exit', listener: (code: number | undefined) => void): this; </del> <ins> on(event: 'exit', listener: (event: Electron.Event, code: number) => void): this; </ins> on(event: 'spawn', listener: () => void): this; } }

Related discussion:
text: Sorry for the regression, but this is a temporary expected breakage because we are updating our supported audio formats , audio cues will be updated to new format this iteration as part of /cc
Sorry about that We just pushed a fix, and the VS Code insiders from tomorrow will have the fix.
Thanks Given this feature turns out to be pretty important for us visually impaired users, would it be possible to create a system test for this? I assume it should be possible to throw a audio cue at FFMPEG and make it fail if the sound doesn't play?
that's a good idea. However I leave this up to since he is driving this from engineering and would have better ideas how we could test it exactly.
We would need a way to ask the OS if an application played some sound.
It works again, at least on my environment. Thanks.
awesome, thanks for letting us know.
I can confirm that it works here as well. Hopefully it stays that way
Code change:
constructor(modulePath: string, args?: string[] | undefined, options?: UtilityProcessOptions); postMessage(channel: string, message: any, transfer?: Electron.MessagePortMain[]): void; kill(signal?: number | string): boolean; <del> on(event: 'exit', listener: (code: number | undefined) => void): this; </del> <ins> on(event: 'exit', listener: (event: Electron.Event, code: number) => void): this; </ins> on(event: 'spawn', listener: () => void): this; } }

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 <!-- 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.66.0 (x64) OS Version: 10.0. Build (Window 10) Steps to Reproduce: VS Code (or use the shortcut ) the first miliseconds after opening a new instance of VS Code, a "Window 7"-like window frame layout appears, before the usual VS Code look shows up (see the attached GIF). The GIF below first shows the expected behavior, opening version 1.65.0, followed by the current behavior of version 1.66.0. ! The two executables were downloaded from: and
Refs
that's the reason I went back to 1.65, frames are so annoying.
Hi just a small update: I've downloaded the latest VS Code Insiders and the problem now only appears when launching VS Code for the first time, but no longer when opening new windows from a running instance of it.
This issue persists in the new latest version release, .
The issue persists in today's release, .
Since the related bug in the Electron repo has a label, and today's VSCode uses , I believe we will be experiencing this bug for months.
The upstream Electron issue is at The issue was introduced in Electron v14.0.0-beta.5 and the commit that introduced the issue is The PR fixes the issue where frameless resizable windows show Windows 7 frames during startup, but there's a larger issue that is still unresolved even with that PR.
Code change:
constructor(modulePath: string, args?: string[] | undefined, options?: UtilityProcessOptions); postMessage(channel: string, message: any, transfer?: Electron.MessagePortMain[]): void; kill(signal?: number | string): boolean; <del> on(event: 'exit', listener: (code: number | undefined) => void): this; </del> <ins> on(event: 'exit', listener: (event: Electron.Event, code: number) => void): this; </ins> on(event: 'spawn', listener: () => void): this; } }

Related discussion:
text: I also searched through the thousands of to see whether they had anything to do with the issue, but I didn't find anything relevant even after reverting several suspicious commits. Running with Electron v14.0.0-beta.5 or newer on Windows 10 reproduces the issue. The PR fixes the issue for frameless resizable windows by calling at an earlier stage of program initialization. Assume the window is frameless and resizable. Then, the program sets to earlier in , and the following occurs: is not run, meaning is not removed from the style set in Line 62. This style parameter is passed in to a call at . is not run. Instead, the block above is run, which adds a style to the style passed into the call. , because of these styles being passed in, after the window is shown, we get a single message, and no messages after. NC in this case refers to non-client area, which is the frame. DWM stands for desktop windows manager. After adding a long of 30 seconds to the call above, I was able to use Spy++ to log messages to that window and see the following: I have also attached full logs to the end of this comment. For frameless windows that cannot resize, even if we call earlier, because the program would pass in , for the and calls above, the style would not be in the styles sent to the calls. As a result, what I see in Spy++ is being toggled three times, and several calls that result in messages being emitted. Using Spy++, I confirmed that the calls have the flag set. I have searched the Chromium and Electron codebases for and (as well as ) to see why the frame might be rendering more often when is not passed in. However, I haven't found anything within the codebase itself. Searching Windows documentation, I found the following: causes to be sent. Reference: However, I'm not sure whether this could explain the difference in behaviour between resizable and non-resizable windows. can pass in or to send to the window, which is why I searched for those two constants within the codebase. Reference: Also, Chromium handles by returning at , which I assume causes the message to occur. Also, Electron calls at .
Code change:
constructor(modulePath: string, args?: string[] | undefined, options?: UtilityProcessOptions); postMessage(channel: string, message: any, transfer?: Electron.MessagePortMain[]): void; kill(signal?: number | string): boolean; <del> on(event: 'exit', listener: (code: number | undefined) => void): this; </del> <ins> on(event: 'exit', listener: (event: Electron.Event, code: number) => void): this; </ins> on(event: 'spawn', listener: () => void): this; } }

Related discussion:
text: I noticed that if I don't call there, the Windows 7 frame doesn't show up, but then the Electron window doesn't render with the proper style (see ). I also noticed that when the Windows 7 frame shows up, it has the style of whatever was passed into that specific call. For example, if I add to the call, then for a second I see a Windows 7 frame with applied. I also tried creating a minimal project in VS to reproduce the issue but wasn't successful. The frame that rendered seemed to have a Windows 10 style rather than a Windows 7 one. I also tried registering a listener in for the messages, and it did seem to get hit, though I couldn't do anything with it. There's also the mysterious , but I wasn't able to apply it to resolve the issue.
The PR that linked above (partially based on ) should resolve the issue for VS Code Insiders and hence close this issue, but there's still more I'd like to investigate, especially for frameless non-resizable windows. I some lines to log the hwnd and style passed into each relevant and call. One example of the styles that show up: There's also another window being created really early, but I don't think it influences the issue. Good scenario (meaning no frame showing) with set to and staying Bad scenario with set to then Bad scenario with set to and staying The call with style causes the Windows 7 frame to render, and its style corresponds to is actually the same style just with , once again showing how mysterious the constant is. While working on , I also noticed that changing the order of the calls seemed to fix the issue for frameless non-resizable windows. In particular, on the Electron side, in , if I first called to pretend that the window is resizable, and then called (where ) after the call around line 365, then the issue is resolved even for frameless non-resizable windows. However, this workaround delays the call to hundreds of lines later, and I wouldn't be surprised if it would cause a regression elsewhere. Just like in the log file of the good case of the previous comment, only shows up once, rather than three times. For completeness, here are the logs with the styles for this scenario, excluding the logs: In this case, the style never comes up!
Code change:
constructor(modulePath: string, args?: string[] | undefined, options?: UtilityProcessOptions); postMessage(channel: string, message: any, transfer?: Electron.MessagePortMain[]): void; kill(signal?: number | string): boolean; <del> on(event: 'exit', listener: (code: number | undefined) => void): this; </del> <ins> on(event: 'exit', listener: (event: Electron.Event, code: number) => void): this; </ins> on(event: 'spawn', listener: () => void): this; } }

Related discussion:
text: I also tried delaying the call and calling instead of , but that doesn't work because it fails to pass to the call as well as the first call, both of which need for the frame not to render: can be used to change the non-client (NC) rendering policy and hence result in a call. However, I did not find any references to within the Electron and Chromium codebases that were actually called when running my minimal repro.
lets continue the investigation in
<!-- 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!
/verified
Code change:
templateData.actionBar.context = <TreeViewItemHandleArg>{ $treeViewId: this.treeViewId, $treeItemHandle: node.handle }; <del> const menuActions = this.menus.getResourceActions(node); if (menuActions.menu) { templateData.elementDisposable.add(menuActions.menu); } </del> <ins> const menuActions = this.menus.getResourceActions(node, templateData.elementDisposable); </ins> templateData.actionBar.push(menuActions.actions, { icon: true, label: false }); if (this._actionRunner) {

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: V1.81.1 OS Version: Linux kkuser-virtual-machine 5.15.0-83-generic ~20.04.1-Ubuntu SMP Mon Aug 21 14:00:49 UTC 2023 x8664 x8664 x8664 GNU/Linux Steps to Reproduce: are constant changes in attribute states in the treeview calls to () functions result in memory leakage
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.82.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
<!-- 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!
Code change:
transformOptimization: false, //(isMacintosh && isNative) || getTitleBarStyle(this.configurationService, this.environmentService) === 'native', initialSize: this._dimension, styleController: (_suffix: string) => { return this._list; }, <del> overrideStyles: this._listStyleOverride, </del> <ins> overrideStyles: { listBackground: notebookEditorBackground, listActiveSelectionBackground: notebookEditorBackground, listActiveSelectionForeground: foreground, listFocusAndSelectionBackground: notebookEditorBackground, listFocusAndSelectionForeground: foreground, listFocusBackground: notebookEditorBackground, listFocusForeground: foreground, listHoverForeground: foreground, listHoverBackground: notebookEditorBackground, listHoverOutline: focusBorder, listFocusOutline: focusBorder, listInactiveSelectionBackground: notebookEditorBackground, listInactiveSelectionForeground: foreground, listInactiveFocusBackground: notebookEditorBackground, listInactiveFocusOutline: notebookEditorBackground, }, </ins> accessibilityProvider: { getAriaLabel: (element: CellViewModel) => { if (!this.viewModel) {

Related discussion:
text: I opened the Settings editor, hovered over a setting, and noticed a new grey line appear to the left of the settings. This issue occurs with the default light and dark themes. !
I found that when calling , if we don't pass in the style override anymore, it will be reset to default I put this fix for notebook but I wonder if it's unexpected
Thanks for figuring that out. We shouldn't update options that are not set, that a regression. I fixed that with and updated your code to back what it was. Is different, it's about the indent guides which were disabled previously by not providing any colors. With my change we complete your colors with the default colors, which IMO is the right thing to do. is a simple fix. But I think we should not use the colors for that but the already existing option. I'm working on a follow up PR, but that needs to be reviewed by who is out today.
Code change:
*--------------------------------------------------------------------------------------------*/ import { DataTransfers, IDragAndDropData } from 'vs/base/browser/dnd'; <del> import { $, addDisposableListener, animate, Dimension, getContentHeight, getContentWidth, getTopLeftOffset, getWindow, isAncestor, isHTMLElement, scheduleAtNextAnimationFrame } from 'vs/base/browser/dom'; </del> <ins> import { $, addDisposableListener, animate, Dimension, getContentHeight, getContentWidth, getTopLeftOffset, getWindow, isAncestor, isHTMLElement, isSVGElement, scheduleAtNextAnimationFrame } from 'vs/base/browser/dom'; </ins> import { DomEmitter } from 'vs/base/browser/event'; import { IMouseWheelEvent } from 'vs/base/browser/mouseEvent'; import { EventType as TouchEventType, Gesture, GestureEvent } from 'vs/base/browser/touch';

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:
} private async enterProfile(profile: IUserDataProfile, preserveData: boolean, reloadMessage?: string): Promise<void> { <del> if (this.environmentService.remoteAuthority) { </del> <ins> const isRemoteWindow = !!this.environmentService.remoteAuthority; if (!isRemoteWindow) { this.extensionService.stopExtensionHosts(); } // In a remote window update current profile before reloading so that data is preserved from current profile if asked to preserve await this.userDataProfileService.updateCurrentProfile(profile, preserveData); if (isRemoteWindow) { </ins> const result = await this.dialogService.confirm({ type: 'info', message: reloadMessage ?? localize('reload message', "Switching a settings profile requires reloading VS Code."),

Related discussion:
text: Type: <bBug</bDev Container with default or the prefered profile a new profile from Current Profile Settings After reloading the window you get a message to install the remote containers extension and when opening the profile in a local workspace you can see that no extensions and no settings where copied from the old profile. VS Code version: Code - Insiders 1.70.0-insider (, 2022-07-08T05:20:13.606Z) OS version: WindowsNT x64 10.0. Modes: Restricted Connection to 'vscode-remote' could not be established No remote extension installed to resolve dev-container. <details<summarySystem Info</summary Connection to 'vscode-remote' could not be established No remote extension installed to resolve dev-container. </detailsExtensions: none <!-- generated by issue reporter --
Code change:
identityProvider: new FileIdentityProvider(), keyboardNavigationLabelProvider: new FileNavigationLabelProvider(), accessibilityProvider: this._instantiationService.createInstance(FileAccessibilityProvider), <ins> showNotFoundMessage: false, </ins> overrideStyles: { listBackground: breadcrumbsPickerBackground },

Related discussion:
text: Type: <bBug</ba file for which a DocumentSymbolProvider will return some items, for example on the filename in the breadcrumb, then type Ctrl/Cmd+F. The list filter widget looks OK, though it hides the first filename in the list ( ought to help with this once merged). the same but one item to the right in the breadcrumb. The filter widget is transparent. ! VS Code version: Code - Insiders 1.71.0-insider (, 2022-08-22T05:16:19.478Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: Yes <!-- generated by issue reporter --
/assign
Easier steps: <kbdCtrl F</kbdon an outline breadcrumb
I still see this. It looks like the background of the find widget gets removed, but the contents still scroll up out of the breadcrumbs widget
Did you test this in dev? Because we still didn't get an Insiders build with the fix.
Code change:
identityProvider: new FileIdentityProvider(), keyboardNavigationLabelProvider: new FileNavigationLabelProvider(), accessibilityProvider: this._instantiationService.createInstance(FileAccessibilityProvider), <ins> showNotFoundMessage: false, </ins> overrideStyles: { listBackground: breadcrumbsPickerBackground },

Related discussion:
text: Originally posted by in
This also happens if step 5 is omitted and Search mode is used. The problem seems to be that to put the 'No elements found.' warning message under the find-in-list's input widget a ContextView is created immediately below it. But when find is occurring in a breadcrumb list, that list is itself in a ContextView which gets hidden and cleared immediately before the one for the warning message is shown. The warning message appears in the top left of the VS Code window in a very narrow column. See below, where I open , click on the filename in the breadcrumb to get a list of sibling filenames, then type "z" which isn't present in any of the filenames. !
Code change:
this._register(this.tree.onDidChangeContentHeight(() => { if (this.tree.scrollHeight !== this.previousTreeScrollHeight) { <del> const lastElementWasVisible = this.tree.scrollTop + this.tree.renderHeight >= this.previousTreeScrollHeight; </del> <ins> // Due to rounding, the scrollTop + renderHeight will not exactly match the scrollHeight. // Consider the tree to be scrolled all the way down if it is within 2px of the bottom. const lastElementWasVisible = this.tree.scrollTop + this.tree.renderHeight >= this.previousTreeScrollHeight - 2; </ins> if (lastElementWasVisible) { setTimeout(() => { // Can't set scrollTop during this event listener, the list might overwrite the change

Related discussion:
text: Splitting from Clone mock-debug Run the tests Resize the window so the debug console has lots of wrapping Run the tests again After a few tests run, the Debug Console will stop scrolling down automatically and just remain part-way through. <img width="838" alt="Screenshot 2021-02-25 at 12 08 28" src="https://user-"
thanks for steps I can reproduce this. here I am hitting the limitation of what the tree gives me. Currently I use the following heurisitc to figure out if the last element is visible in the tree However that does not give the correct result when elements are wrapped and take additional lines. So I could either somehow update that check, or I could use the . I would just care if there are elements after the last visible element, but I could not figure out any tree api to get next neighbour of the last visible element. Might I be missing something? Let me know what you think, thanks.
What 3 values does it return in that case?
In this step we are good: In the next step we are no longer good:
and me investigated into this and it seems to be related to how async code is handled on the list side. Thus assigning this to on-deck and once finds time he can look into a fix or recommend a workaround for me on the Debug Console side.
Any progress on this issue? Would be great to not have to manually scroll down during the debug session.
Not to my knowledge. I've been told a small trick though In the debug console, hit Shift+Tab to move focus from the input box to the output list. Now you can just hit End once to move to the end of the list.
thanks for the tip, but going through all that hassle every single time I type in a command in the debug console or try to inspect a variable by printing out its type is simply not worth it. are there any viable workarounds to this? I believe it makes the debug console pretty much impossible to use for the average python developer.
Workaround is As for progress, we plan to fix this however not sure when. did an initial investigation and it proved more complex than anticipated.
Thanks for your valuable feedback. This works for me. I should probably add that should be to the and not the Just out of curiosity, doesn't that basically solve the problem?