jiebi/CodeConvo huggingface dataset:
Change:
position: absolute; pointer-events: none; z-index: 1; <del> padding: 2px 6px 3px 6px; </del> <ins> padding: 3px 6px; </ins> box-sizing: border-box; width: 100%; overflow: hidden;

Discussion:
It doesn't look right compared to all the other placeholders: ! It's more noticeable when using editor font (font gets smaller): VS Code version: Code - Insiders 1.56.0-insider (, 2021-04-16T11:25:09.662Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
Change:
provideColors(resource: URI, token: CancellationToken): Promise<extHostProtocol.IRawColorInfo[]> { const doc = this._documents.getDocument(resource); return asPromise(() => this._provider.provideDocumentColors(doc, token)).then(colors => { <del> if (!Array.isArray<vscode.ColorInformation>(colors)) { </del> <ins> if (!Array.isArray(colors)) { </ins> return []; }

Discussion:
What is the reasoning behind not allowing via the Monaco standalone editor checks? It seems to be valid ES6 when I look at where it is defined:
idk - requires at least edge 14, unsure what our edge minimum version is:
Looking at the compat tables, I think it should be safe to use it. I guess it must have been a left-over from the IE era. I don't remember adding any rule like this, so I don't know where to begin looking to remove it. Leaving it to you .
I opened to do this and it has the advantage that we can get rid of another file in our folder () which actually even seems to have the wrong signature compared to TS. According to , Edge 13 has very low usages and Edge 14 is out since 2016: !
Unsure how and are connected. Or is this two clean-ups in one? I have the latter because for the longest time there was a TS bug which would remove type info from arrays after checking E.g If that's now fixed, I am very happy with removing
ah good to know, I just checked both in our code and the playground and I see that this no longer seems to be the case: ! I will go ahead and merge my PR then.
it
Change:
return; } <ins> if (activeHover) { toggleCustomHover(activeHover, widget); } </ins> await updateFocus(widget, updateFocusFn); const listFocus = widget.getFocus();

Discussion:
macOS, VS Code Insiders into explorer focus via keyboard hover does not show. There is no command to trigger the custom hover to show Like the activity bar, we have to make sure that the custom hover can be accessed in the tree/list only with the keyboard.
Would you suggest adding a keybinding to toggle the visibility of the custom hover of the html element which has focus?
Yeah, ideally it is . The same shortcut that we use in the editor for showing the hover. So it is consistent and easy for user to understand that there is one shortcut which does the right thing everywhere.
Isn't this a duplicate of ? Btw we seem to be having this support for extension provided trees at least:
I think it's good to have this one separate to .
Solving this for all trees/lists is pretty hard as the tree/list does not know anything about the underlying elements being rendered. For extension trees it is much easier as they all consist of a label which the creates and controls.
One option could be to utilize the to get the tooltip. Currently it already provides
After further discussions we came to the conclusion that we would use the DOM tree to figure out if there is any custom hovers available and trigger the hover by dispatching a mouse event on the HTMLElement. This might seem rather hacky but it ensures the consumers of the tree only have to support hover once and lets the tree handle keyboard triggers. Handling focus is still tricky and a open problem. Until this focus problem is properly fixed the treeview will keep it's own implementation which directly uses the hover service and moves the focus into the hover. The treeview implementation of this has it's own flaws but will b kept for the meantime to not cause regressions.
Change:
'use strict'; import nls = require('vs/nls'); <del> import errors = require('vs/base/common/errors'); </del> import strings = require('vs/base/common/strings'); import scorer = require('vs/base/common/scorer'); import { TPromise } from 'vs/base/common/winjs.base'; import { Mode, IEntryRunContext, IAutoFocus, IQuickNavigateConfiguration, IModel } from 'vs/base/parts/quickopen/common/quickOpen'; <del> import { QuickOpenModel, QuickOpenEntryGroup, QuickOpenEntry } from 'vs/base/parts/quickopen/browser/quickOpenModel'; </del> <ins> import { QuickOpenModel, QuickOpenEntry } from 'vs/base/parts/quickopen/browser/quickOpenModel'; </ins> import { QuickOpenHandler } from 'vs/workbench/browser/quickopen'; import { ITerminalService } from 'vs/workbench/parts/terminal/common/terminal'; import { IPanelService } from 'vs/workbench/services/panel/common/panelService'; import { ContributableActionProvider } from 'vs/workbench/browser/actions'; <del> export class TerminalEntry extends QuickOpenEntryGroup { </del> <ins> export class TerminalEntry extends QuickOpenEntry { </ins> constructor( private label: string, <del> private open: () => void </del> <ins> private terminalService: ITerminalService </ins> ) { super(); }

Discussion:
VSCode Version: Code - Insiders 1.15.0-insider (, 2017-08-04T17:43:56.658Z) OS Version: Darwin x64 16.7.0 After having used the terminal switcher for a few days, I realize that I'm always assuming that the keyboard focus moves when I change the active terminal, same what happens when using from the command pallet. As it doesn't I often end up doing the wrong thing, i.e. type shell commands in the open editor, etc. Steps to Reproduce: two terminals and one editor the keyboard focus in the editor to change the visible terminal typing -the editor content is being modified <!-- Launch with to check. --Reproduces without extensions: Yes
Change:
position: absolute; top: 0; left: 0; <del> z-index: 5; </del> <ins> z-index: 20; </ins> pointer-events: none; background-color: var(--separator-border); }

Discussion:
!
regression from
looping you in here too. This is more tricky as it seems I believe boils down to the zindex of the sash being to weak. Tho, I can't find a working value that is strong I have tried various things in sticky-scroll land w/o success. I can't "indent" its contents because than line numbers and contents aren't aligned. I cannot lower its zindex because than zone widgets overflow it...
That's odd. The sash is transparent: it shouldn't render at all, unless you hover it. Are you sure this is the sash?
Might actually not be the sash but from the split view
Yeah, settings its actually fixes this issue
- it does use a "random" zindex to fix it
Change:
}); registerTerminalAction({ <del> id: TerminalCommandId.ScrollToTop, title: localize2('workbench.action.terminal.scrollToTop', 'Scroll to Top'), </del> <ins> id: TerminalCommandId.ScrollToTopAccessibleView, title: localize2('workbench.action.terminal.scrollToTopAccessibleView', 'Scroll to Accessible View Top'), </ins> precondition: ContextKeyExpr.and(ContextKeyExpr.or(TerminalContextKeys.processSupported, TerminalContextKeys.terminalHasBeenCreated), ContextKeyExpr.and(accessibleViewIsShown, ContextKeyExpr.equals(accessibleViewCurrentProviderId.key, AccessibleViewProviderId.Terminal))), keybinding: { primary: KeyMod.CtrlCmd | KeyCode.Home,

Discussion:
I have noticed that some Action2 instances are registered that reuse an id. That's not OK because Action2 is a singleton model object, e.g it keybinding or menu registrations refer to it by id. This should be cleaned up and from then on it should be an error to reuse an id [x] [x] [x] [x] [x] command 'toggleVisibility' [x] command 'removeView'
I believe this is all the same issue somewhere in views land?
This is how these actions are registered May I know what is the suggested approach?
Don't register them twice
fixes duplication in view land by first disposing old action and only then creating new ones
you are new to this issue, there are ids that are reused for Action2 and those need to be fixed. Today, this prints a warning but it this become an error soon
Adding for
Change:
{ "type": "node", "request": "launch", <del> "name": "Unit Tests", "program": "${workspaceFolder}/node_modules/mocha/bin/_mocha", </del> <ins> "name": "Run Unit Tests", "program": "${workspaceFolder}/test/electron/index.js", </ins> "runtimeExecutable": "${workspaceFolder}/.build/electron/Code - OSS.app/Contents/MacOS/Electron", "windows": { "runtimeExecutable": "${workspaceFolder}/.build/electron/Code - OSS.exe"

Discussion:
Issue Type: <bBug</bRepo VS Code code base launch the debug configuration Bug In the debug console, see the following error: I've tried a clean and rebuild but haven't been able to get this working VS Code version: Code - Insiders 1.30.0-insider (, 2018-11-19T19:59:44.607Z) OS version: Darwin x64 18.2.0 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
After disabling the uri check temporarily, I now get:
Not my launch-config. TBH - I have never used our debugger for tests, I use
I didn't know about the --debug option. I've never understood why the debug config setup is totally different than the typical running setup. Why don't we launch in the same way as --debug but attach the vscode debugger? I'll take a look when I get a chance.
Change:
// the prompt being written this._capabilities.get(TerminalCapability.CommandDetection)?.handlePromptStart(); this._capabilities.get(TerminalCapability.CommandDetection)?.handleCommandStart(); <ins> alert(localize('terminalCleared', "Cleared")); </ins> } hasSelection(): boolean {

Discussion:
Reported by Use or as a SR user. there's no indication that that has succeeded. We could alert with info or use an audio cue
I don't see the chat clear history action in core, so we'd need to do this in the extension. There's a clear input history, though I don't think we want to alert for that case.
Actually, found it
Change:
export function setup(ensureStableCode: () => string | undefined, logger: Logger) { describe('Data Loss (insiders -> insiders)', function () { <ins> // Double the timeout since these tests involve 2 startups this.timeout(4 * 60 * 1000); </ins> let app: Application | undefined = undefined; // Shared before/after handling

Discussion:
Callstack is similar to the one mentioned in but the issue remains First failure Second failure
The logs read very normal, we literally hit the 2min timeout. Since these tests do double the work (start VS Code 2 times), I will see if increasing the timeout helps.
Change:
(valueType === 'boolean' && !canBeType(typeArr, 'boolean')) || (valueType === 'object' && !canBeType(typeArr, 'object', 'null', 'array')) || (valueType === 'string' && !canBeType(typeArr, 'string', 'number', 'integer')) || <del> (typeof parseFloat(value) === 'number' && !isNaN(parseFloat(value)) && !canBeType(typeArr, 'number', 'integer')) || </del> (Array.isArray(value) && !canBeType(typeArr, 'array')) ) { if (typeof type !== 'undefined') {

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.45.0 OS Version: macOS Catalina 10.15.4 ! My file: The setting does work, it just shows that warning. Steps to Reproduce: on "Edit in " under "Editor: Rulers" any number inside of the array for the field "" <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Bug in my validation !
This affects all numeric array settings, and also numeric values in "string" type settings.
Any idea why this is just now showing up? Looks like the code is old and I'm pretty sure I've use the UI for rulers before.
I only those validations last month.
My bad, read the "a month ago" as "8 month ago".
Better fix in
as of firiday may 15 this issue is NOT corrected ! !
looks like settings with type and default still error in Stable. It's already fixed in Insiders.
Dang. Sorry it will be fixed in the next release.
I am getting this for certain "boolean", will the fix address them too?
Can you try downloading the Insiders' build and tell me whether it happens there? If so, can you tell me which setting it is?
Hi Rob, it works fine with insiders version Rob Lourens <:
Change:
} else if (overwriteAfter === 0 && (word = model.getWordAtPosition(position))) { // compute fallback overwrite length <del> overwriteAfter = word.endColumn - position.column; </del> <ins> overwriteAfter = word.endColumn - editorPosition.column; </ins> } SnippetController2.get(this._editor).insert(insertText, {

Discussion:
<!-- 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.40.0-insider () OS Version: macOSX 10.15 Steps to Reproduce: auto-complete and press tab <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes 40.0-insider () ! 1.38.1 () !
works fine seems to be broken
thanks for bisecting. was authered by thus assigning to him
Yup, this is bad: ! Though it only happens on auto suggest, not manual trigger.
I've merged the fix by thanks a lot for that! We'll get the fixed Insiders build next Monday morning CET. Sorry for the disturbance everyone!
Thanks everyone!
Still seeing this pretty consistently on Version: 1.40.0-insider (user setup) Commit: Date: 2019-10-15T05:26:38.861Z Electron: 6.0.12 Chrome: 76.0.3809.146 12.4.0 V8: 7.6.303.31-electron.0 OS: Windows_NT x64 10.0. ! Unless this is now the correct behavior? In which case, how do I stop it and get it to insert as before, not replace?
I'm seeing weird behavior on quotes as well. if you type inside , the last quote is removed, like in becomes Version: 1.40.0-insider (user setup) Commit: Date: 2019-10-15T05:26:38.861Z Electron: 6.0.12 Chrome: 76.0.3809.146 12.4.0 V8: 7.6.303.31-electron.0 OS: Windows_NT x64 10.0.
What language is that?
Oh, I see . Yeah, that's very likely because JSON uses a more than bogous word definition
I have created and I aiming to push a fix today
What's the correct behavior here?

If replacing the text is correct, that's fine, but if the current solution is going to be a whack-a-mole fix for each language maybe there's something else that should be done.
Another example. On this one, the comma is removed: !
We appreciate constructive feedback, if you want to report an issue then please file a new issue, stating the version of vscode, the language, and exact repo steps.
It's not a different issue though, this one just isn't fixed regardless of my preference for replace vs insert. If you'd prefer, I can open a new one.
Things seem to be working in the latest insiders. I'm no longer able to repro issue--can you confirm that this still occurs on the latest build of insiders? 
Yeah I haven't noticed any weird behavior in the past few days. I'll certainly comment here if I see it again.
Change:
*/ export const editorLightBulbForeground = registerColor('editorLightBulb.foreground', { dark: '#FFCC00', light: '#DDB100', hcDark: '#FFCC00', hcLight: '#007ACC' }, nls.localize('editorLightBulbForeground', "The color used for the lightbulb actions icon.")); export const editorLightBulbAutoFixForeground = registerColor('editorLightBulbAutoFix.foreground', { dark: '#75BEFF', light: '#007ACC', hcDark: '#75BEFF', hcLight: '#007ACC' }, nls.localize('editorLightBulbAutoFixForeground', "The color used for the lightbulb auto fix actions icon.")); <del> export const editorLightBulbAiForeground = registerColor('editorLightBulbAi.foreground', { dark: darken(iconForeground, 0.4), light: lighten(iconForeground, 1.7), hcDark: iconForeground, hcLight: iconForeground }, nls.localize('editorLightBulbAiForeground', "The color used for the lightbulb AI icon.")); </del> <ins> export const editorLightBulbAiForeground = registerColor('editorLightBulbAi.foreground', { dark: darken(iconForeground, 0.4), light: lighten(iconForeground, 1), hcDark: iconForeground, hcLight: iconForeground }, nls.localize('editorLightBulbAiForeground', "The color used for the lightbulb AI icon.")); </ins> /** * Diff Editor Colors

Discussion:
Use "Github Light Theme" from the sparkle lightbulb seems to be the same color as the editor background <img width="212" alt="Screenshot 2023-12-01 at 10 42 28" src=""
I can decrease the value of the lightening factor. This will however mean that the sparkles will be darker on other light themes.
Change:
}); template.context = dataElement; <ins> template.elementDisposables.add(toDisposable(() => { template.listWidget.cancelEdit(); })); </ins> template.onChange = (v) => { onChange(v); renderArrayValidations(dataElement, template, v, false);

Discussion:
On Linux: the settings editor type out "cellToolbarLocation" way through, when the setting comes up, focus is stolen by the "item" in the table !
Yikes. I wonder if you could look at this
I'm unable to repro this on both Windows and Mac. It takes me a double-click to manually change the first row of that setting into edit mode, after it shows up. Do we have any OS-specific code for the settings editor If not, I wonder if this might be an Electron issue.
I did not repro on Windows either, only in Linux
I can on mac, if I have multiple rows on the setting. Or maybe I had to interact with the setting in that editor previously. I can't remember whether there is some code on the list setting widget that tries to restore focus after a change. I just called you out because I thought you might have seen that recently
Ok, reproduced the issue on Mac but not Windows with your hint there: -click the first item in the cell toolbar location setting to get it into edit mode. of pressing the OK or Cancel button, close the setting editor. the setting editor again, and slowly type . :bug: The setting shows up with the first item in edit mode, and that seems to steal focus away.
In , there are some areas where gets called. I think a solution to this approach would be to call whenever the user focuses back onto the main search bar, or if the settings editor tab is closed. Otherwise, on all OSes, when the user focuses back onto the search bar, and tries to search a new setting, the focus is stolen back to the item in edit mode.
Change:
padding: 0; } <ins> .monaco-workbench .inline-chat-content-widget.interactive-session .interactive-list { display: none; } </ins> .monaco-workbench .inline-chat-content-widget.interactive-session .toolbar { display: none; padding-top: 4px;

Discussion:
Testing text buttons and reload typing, then hit tab once. Tab goes to microphone tab again can't tell where the focus is. It's not on the "enter to send" button, because I can see that focus moves there on a subsequent, third, tab. !
Looks like the (empty) list below grabs focus... <img width="1298" alt="Screenshot 2024-06-25 at 14 12 05" src=""
Verified but noticed that the hover feedback on this button is only the hover: !
Change:
import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; import { IEditorOptions } from 'vs/platform/editor/common/editor'; import { NativeParsedArgs } from 'vs/platform/environment/common/argv'; <del> import { IEnvironmentService } from 'vs/platform/environment/common/environment'; </del> import { FileType } from 'vs/platform/files/common/files'; import { LogLevel } from 'vs/platform/log/common/log'; import { PolicyDefinition, PolicyValue } from 'vs/platform/policy/common/policy';

Discussion:
I tried enabling it in my Code-OSS settings but it didn't seem to work. The sentence from that I quoted make me think it had been hardwired off in Code-OSS. I haven't searched the codebase yet though. Originally posted by in
OSS does seem to have the WCO disabled. says that WCO was disabled in OSS due to upstream issues, but there's been a bunch of fixes recently, so it's probably OK to enable it again.
Verification steps: the WCO in OSS by enabling the setting. VS Code when prompted and change the colour theme. Windows 11, one can verify the WCO has been enabled by checking that the snap layout UX is available. On Windows 10, one can verify the WCO has been enabled by switching through colour themes and checking that the area with the minimize/maximize/close buttons updates its colours before the rest of the titlebar does.
Change:
export const VS_DARK_THEME = 'vs-dark'; export const VS_HC_THEME = 'hc-black'; <ins> export const HC_THEME_ID = 'Default High Contrast'; </ins> export const COLOR_THEME_SETTING = 'workbench.colorTheme'; <ins> export const DETECT_HC_SETTING = 'window.autoDetectHighContrast'; </ins> export const ICON_THEME_SETTING = 'workbench.iconTheme'; export const CUSTOM_WORKBENCH_COLORS_SETTING = 'workbench.colorCustomizations'; export const CUSTOM_EDITOR_COLORS_SETTING = 'editor.tokenColorCustomizations';

Discussion:
(Moved from internal Windows Feedback bug database) on High Contrast Black VS Code that inside of the frame, the text shows up normally (not in high contrast). This is an accessibility issue
The current workaround is to manually switch VS Code to the High Contrast Theme via
is there electron API to detect high contrast mode automatically?
Yeah I thought we detect high contrast on Windows, I have to check.
I see that the theme is correctly passed on to the renderer () but then is reset back to the previous one (e.g. ). Can you check why the theme is not applied? To reproduce: enable HC theme on Windows start VS Code expect it to show in HC theme
The hc theme needs to be set in the settings or on the theme service, like (). This will trigger all theming participants that then ally the theming and generate the css rules. Setting the class name just helps with the initial window appearance.
it looks like you removed that code that handles high contrast on Windows and never it back to the renderer ()? I created to prefer the HC theme if we detect high contrast mode. It is a bit ugly though because the settings are still containing the previous theme, not sure we should just blindly overwrite it because the HC theme on Windows could be a temporary thing.
Change:
create(resource: URI, contents?: VSBuffer | VSBufferReadable | VSBufferReadableStream, options?: { overwrite?: boolean }): Promise<IFileStatWithMetadata>; /** <ins> * Will create a folder and any parent folder that needs to be created. * * Working copy owners can listen to the `onWillRunWorkingCopyFileOperation` and * `onDidRunWorkingCopyFileOperation` events to participate. * * Note: events will only be emitted for the provided resource, but not any * parent folders that are being created as part of the operation. */ createFolder(resource: URI): Promise<IFileStatWithMetadata>; /** </ins> * Will move working copies matching the provided resources and corresponding children * to the target resources using the associated file service for those resources. *

Discussion:
It does fire for folder on move and delete. According to the reason lies here: The code goes directly to the file service. Since we correctly report move and delete for folders I think we should report create as well.
Some background: I want to adopt this in LSP but specing that this only works for move and delete of folders sounds a little silly. So I want to make sure that there is either a very compelling reason or there is some ack. that we will fix it in the future.
We currently have no related method such as for folders that the explorer could use here: If we support this, I guess one question in terms of API breakage is wether it is fine to let and emit events for folders too while they currently only emit for files. If we think this is fine, then I think this would be a relatively simple change to make.
I don't consider that breakage, it's a bug fix esp. given that move and delete already fire events for both
Verification: write an extension that registers to and and verify you see both events when you right click into the explorer and create a new folder.
Thanks for fixing!