jiebi/CodeConvo huggingface dataset:
Change:
Testing Issue Type: <bBug</bextension search box. type every half second or so (make sure the progress bar is showing when you type the next space) Bug After five or more spaces, the entire VS Code UI starts hanging for a few seconds VS Code version: Code - Insiders 1.26.0-insider (, 2018-07-31T05:12:08.688Z) OS version: Darwin x64 17.7.0 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Are you able to reproduce this reliably? I've never gotten it on Windows but I did manage once on macOS, even then it only stalled the extensions viewlet UI, rest was fine. Its just pressing space as the search triggers right?
Can we not skip the search if () === () ?
We can do that. But what if they hit 'a' a bunch? can you repro this in stable?
No, I didn’t see this in stable when typing spaces. I also don’t remember being able to reproduce this with other characters, such as typing “a” many times
Then we can probably get away with just debouncing the trimmed value
Let's do that to begin with

Discussion:
const searchChangeEvent = new Emitter<string>(); this.onSearchChange = searchChangeEvent.event; <ins> let existingContent = this.searchBox.getValue().trim(); </ins> this.disposables.push(this.searchBox.getModel().onDidChangeContent(() => { <ins> this.placeholderText.style.visibility = this.searchBox.getValue() ? 'hidden' : 'visible'; let content = this.searchBox.getValue().trim(); if (existingContent === content) { return; } </ins> this.triggerSearch(); <del> const content = this.searchBox.getValue(); </del> searchChangeEvent.fire(content); <del> this.placeholderText.style.visibility = content ? 'hidden' : 'visible'; </del> <ins> existingContent = content; </ins> })); return super.create(this.extensionsBox)
Change:
Steps to Reproduce: issue reporter extension view. spaces in the extension search box, one ever half second or so. Make sure the progress bar is showing when you type the next space switch focus back to issue reporter and click on an input box Bug Issue reporter freaks out and starts inserting endless spaces (almost like it has a stuck key) ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No

Discussion:
const searchChangeEvent = new Emitter<string>(); this.onSearchChange = searchChangeEvent.event; <ins> let existingContent = this.searchBox.getValue().trim(); </ins> this.disposables.push(this.searchBox.getModel().onDidChangeContent(() => { <ins> this.placeholderText.style.visibility = this.searchBox.getValue() ? 'hidden' : 'visible'; let content = this.searchBox.getValue().trim(); if (existingContent === content) { return; } </ins> this.triggerSearch(); <del> const content = this.searchBox.getValue(); </del> searchChangeEvent.fire(content); <del> this.placeholderText.style.visibility = content ? 'hidden' : 'visible'; </del> <ins> existingContent = content; </ins> })); return super.create(this.extensionsBox)
Change:
Issue Type: <bBug</bSimilar issue as but I managed to find a way to reproduce it (occurs at least on previews, been unable to test on comparisons, but if it occurs on simple previews I'd imagine it's likely for all image displays). Searching issues leads to a lot of references to , possibly related? Steps to reproduce: Code an image +mouse wheel should correctly zoom in with scroll up, and out with down. to pan the image by left-click and dragging (not something Code seems to support). zoom should now be inverted. Restarting Code usually fixes it until reproduced again, but not always. Re-launching without an image open and opening/scrolling in some other text-based files seems to help. Does this issue occur when all extensions are disabled?: Yes VS Code version: Code 1.25.1 (, 2018-07-11T15:43:53.668Z) OS version: WindowsNT x64 6.1.7601 <details<summarySystem Info</summary </details<details<summaryExtensions (9)</summaryExtensionVersion ------ bracket-pair-colorizer1.0.59 tslint1.0.34 vscode-npm-script0.3.5 vscode-todo-plus2.2.1 vscode-firefox-debug1.4.3 svn-scm1.31.0 debugger-for-chrome4.8.2 material-icon-theme3.5.2 vscode-todo-highlight1.0.4 (1 theme extensions excluded) </details<!-- generated by issue reporter --
Does this still reproduce in the ?
Latest insiders seems to be always inverted.
It's always inverted for me (not insiders).
I would like to give it a try.

Discussion:
firstZoom(); } <del> let delta = e.deltaY < 0 ? 1 : -1; </del> <ins> let delta = e.deltaY > 0 ? 1 : -1; </ins> <del> // Pinching should increase the scale if (e.ctrlKey && !isScrollWheelKeyPressed) { delta *= -1; } </del> updateScale(scale as number * (1 - delta * InlineImageView.SCALE_PINCH_FACTOR)); }));
Change:
Delete a file. Attempt to undo the deletion. See error message: ! This could stand to be more clear. It makes sense on the technical side, but some git novices might be confused. I personally had to double check I was reverting the right change.
I think changing the message to is ok when discarding the changes in a deleted file.

Discussion:
message = localize('confirm delete', "Are you sure you want to DELETE {0}?", path.basename(scmResources[0].resourceUri.fsPath)); yes = localize('delete file', "Delete file"); } else { <del> message = localize('confirm discard', "Are you sure you want to discard changes in {0}?", path.basename(scmResources[0].resourceUri.fsPath)); </del> <ins> if (scmResources[0].type === Status.DELETED) { yes = localize('restore file', "Restore file"); message = localize('confirm restore', "Are you sure you want to restore {0}?", path.basename(scmResources[0].resourceUri.fsPath)); } else { message = localize('confirm discard', "Are you sure you want to discard changes in {0}?", path.basename(scmResources[0].resourceUri.fsPath)); } </ins> } } else { <del> message = localize('confirm discard multiple', "Are you sure you want to discard changes in {0} files?", scmResources.length); </del> <ins> if (scmResources.every(resource => resource.type === Status.DELETED)) { yes = localize('restore files', "Restore files"); message = localize('confirm restore multiple', "Are you sure you want to restore {0} files?", scmResources.length); } else { message = localize('confirm discard multiple', "Are you sure you want to discard changes in {0} files?", scmResources.length); } </ins> if (untrackedCount > 0) { message = `${message}nn${localize('warn untracked', "This will DELETE {0} untracked files!", untrackedCount)}`;
Change:
Because both colors are blue they become hard to read and fail the color contrast ratio. Would expect for the highlighted text in these selected states to become white. Outline Breadcrumb cc
can you also attach the look for quick open after this change? and would this change be for the light theme only or all themes?
I can't find an example that uses selection for quick open, do you know of one? And this change would be the new default for the breadcrumb/outline view, so it would affect all themes that use the "light theme" defaults in those two views. It's currently broken and was hard to see in our previous color as well: !
yeah, none of the pickers use selection color, I was more referring to how quick open would look like if you change highlight color to white. My understanding is that this would have an impact pretty much everywhere where highlighting is being used (independent from the tree or not)
To clarify: this would affect all light themes, even the ones in the market place? or only our light theme
sorry if I wasn't clear, my intention is to only change the highlight color when it's on a selection row. So I'm not intending to change the default highlight color. In the example below, the highlight color remains the same except when it's selected: ! I still need to investigate how to do this, but my suspicion is that we already make the text lighter on a selected row, so I'd explore doing something like while it's selected. yes, this would affect all light themes.
but there is only , we do not distinguish the highlight color based on the type of selection currently. that sounds like it could break many themes because the change from our current blue to white is quite a different color. if this was an issue for any of the themes in the marketplace, they would have fixed this already I suppose.
me do some investigation to figure this one out.
I think the point is the we don't have (and want) a highlighted-and-selected-foregournd-color but that the selection color always wins.
The highlight color on the dark theme also fails the color contrast ratio (3.2:1): !

Discussion:
display: none; } <del> .monaco-tree.focused .selected .outline-element-label, .monaco-tree.focused .selected .outline-element-decoration { </del> <ins> .monaco-tree.focused .selected .outline-element-label, .monaco-tree.focused .selected .outline-element-decoration{ </ins> /* make sure selection color wins when a label is being selected */ color: inherit !important; } <ins> .monaco-tree.focused .selected .outline-element-label .monaco-highlighted-label .highlight, .monaco-tree.focused .selected .monaco-icon-label .monaco-highlighted-label .highlight{ /* allows text color to use the default when selected  */ color: inherit !important; } </ins> .monaco-workbench .outline-panel.no-icons .outline-element .outline-element-icon { display: none; }
Change:
! See the right side. I think the editor instance width needs to account for the parent padding.
What theme is this?
Monokai

Discussion:
this.layoutTrees(dimension); let innerWidth = dimension.width - 24 * 2; // 24px padding on left and right <del> let monacoWidth = (innerWidth > 1000 ? 1000 : innerWidth - 10); </del> <ins> let monacoWidth = (innerWidth > 1000 ? 1000 : innerWidth) - 10; </ins> this.searchWidget.layout({ height: 20, width: monacoWidth }); DOM.toggleClass(this.rootElement, 'narrow', dimension.width < 600);
Change:
Preferences Settings New settings editor opened Just in the native menu. The revert brought back the code that opens the new editor.

Discussion:
} private getPreferencesMenu(): Electron.MenuItem { <del> const settings = this.createMenuItem(nls.localize({ key: 'miOpenSettings', comment: ['&& denotes a mnemonic'] }, "&&Settings"), 'workbench.action.openSettings2'); </del> <ins> const settings = this.createMenuItem(nls.localize({ key: 'miOpenSettings', comment: ['&& denotes a mnemonic'] }, "&&Settings"), 'workbench.action.openSettings'); </ins> const kebindingSettings = this.createMenuItem(nls.localize({ key: 'miOpenKeymap', comment: ['&& denotes a mnemonic'] }, "&&Keyboard Shortcuts"), 'workbench.action.openGlobalKeybindings'); const keymapExtensions = this.createMenuItem(nls.localize({ key: 'miOpenKeymapExtensions', comment: ['&& denotes a mnemonic'] }, "&&Keymap Extensions"), 'workbench.extensions.action.showRecommendedKeymapExtensions'); const snippetsSettings = this.createMenuItem(nls.localize({ key: 'miOpenSnippets', comment: ['&& denotes a mnemonic'] }, "User &&Snippets"), 'workbench.action.openSnippets');
Change:
Issue Type: <bBug</bCompared to input boxes in other viewlets, the search box in the extensions viewlets looks slightly different with a little padding of a different color inside the box. VS Code version: Code - Insiders 1.27.0-insider (, 2018-08-15T05:19:24.200Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<!-- generated by issue reporter --
This appears to be because the sets the background color to a transparent color (), if that is changed to , the look is the same but without the border. This seems like incorrect behavior of the renderer, as the type of color shouldn't affect what gets colored.
Actually, looks like the transparency is showing up differently on the different backgrounds. If you increase the alpha, it starts to look like this: ! I'll look in to making the transparency affect both equally

Discussion:
.suggest-input-container .monaco-editor, .suggest-input-container .mtk1 { /* allow the embedded monaco to be styled from the outer context */ <del> background-color: inherit; </del> <ins> background-color: transparent; </ins> color: inherit; }
Change:
Now that has been to the API, I would like to support the proposal from to use it for tagging deprecated items. I figure the associated styling might be a strikethrough as proposed in but you guys can work that out separately.
I would be interested in helping out here with this and perhaps even . Without a lot of context, I assume this issue is specifically to add a new enum member here: I could open a PR that adds a member, if that's the case. edit: Looks like more applicable location would be and then opening a similar PR to
Yes, is the way to go. Find your way along usages/implementations of
Thanks, I'll work on that today.
Leaving this open so that we discuss this in the API sync
API has been finalised.

Discussion:
if (unnecessaryBorder) { collector.addRule(`.${SHOW_UNUSED_ENABLED_CLASS} .monaco-editor .${ClassName.EditorUnnecessaryDecoration} { border-bottom: 2px dashed ${unnecessaryBorder}; }`); } <ins> collector.addRule(`.monaco-editor .${ClassName.EditorDeprecatedInlineDecoration} { text-decoration: strikethrough; }`); </ins> });

EditorWarningDecoration = 'squiggly-warning', EditorErrorDecoration = 'squiggly-error', EditorUnnecessaryDecoration = 'squiggly-unnecessary', <del> EditorUnnecessaryInlineDecoration = 'squiggly-inline-unnecessary' </del> <ins> EditorUnnecessaryInlineDecoration = 'squiggly-inline-unnecessary', EditorDeprecatedInlineDecoration = 'squiggly-inline-deprecated' </ins> } export const enum NodeColor {

if (marker.tags.indexOf(MarkerTag.Unnecessary) !== -1) { inlineClassName = ClassName.EditorUnnecessaryInlineDecoration; } <ins> if (marker.tags.indexOf(MarkerTag.Deprecated) !== -1) { inlineClassName = ClassName.EditorDeprecatedInlineDecoration; } </ins> } return {

export enum MarkerTag { <del> Unnecessary = 1 </del> <ins> Unnecessary = 1, Deprecated = 2 </ins> } export enum MarkerSeverity {

export const enum MarkerTag { Unnecessary = 1, <ins> Deprecated = 2 </ins> } export enum MarkerSeverity {

} //#endregion <ins> //#region Deprecated support export enum DiagnosticTag { /** * Deprecated or obsolete code * * Can be used to style with strikeout or other "obsolete" styling. See: * https://github.com/microsoft/vscode/issues/50972 */ Deprecated = 2, } //#endregion </ins> }

switch (value) { case types.DiagnosticTag.Unnecessary: return MarkerTag.Unnecessary; <ins> case types.DiagnosticTag.Deprecated: return MarkerTag.Deprecated; </ins> } return undefined; }

export enum DiagnosticTag { Unnecessary = 1, <ins> Deprecated = 2 </ins> } export enum DiagnosticSeverity {
Change:
Environment Details: VSCode Version : 1.24.0 OS Version : Win10 Additional Details: MAS Violated : MAS 1.4.3 Tools Used : Color Contrast Analyzer Repro Steps: 1)Navigate to Settings--Select color theme --Select Quiet light. 2)Check color contrast ratio for the Explorer content on the screen. Actual: Color contrast ratio is less than 4.5:1 for the black colored content when focused. Similar issue is observed in following themes: Abyss Kimbie dark Monokai Dimmed High contrast Install additional color theme Expected: Color contrast ratio should be more than 4.5:1 for the content on a screen. Recommendations: Refer below link which is repository of bug fixes code snippets:   User Impact: The low vision/visually impaired users will not be able to view the content properly. MAS Reference: MAS 1.4.3 - {-765f-489c-b18f-}  Attachment For Reference: ! Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.981 --- <!-- score: 0.924 --- <!-- score: 0.875 --- <!-- score: 0.869 --- <!-- score: 0.867 --<!-- potentialduplicates_comment --
Per our agreement, we will not be fixing color contrast issues with third party themes. cc
just a note that we are the authors of this theme (actually I am the original author) Does this mean that we only fix for the Light+ and Dark+?
we're supposed to fix any issues for themes that we own and ship with out of the box (except for third party themes we don't own). I didn't know we own QuietLight so I'll re-open.
Checked and verified in below version i.e 1.27.0-Insiders. The issue still exist in Quite Light theme. Similar issue is observed in following themes: 1)Solarized light:All the text in the page fail in color contrast ratio i.e 4.5:1 2)Light visual studio: Black coloured text fail in color contrast ratio i.e 4.5:1
please see for the unused variable color issues

Discussion:
"variable.language" ], "settings": { <del> "foreground": "#AB6526" </del> <ins> "foreground": "#9C5D27" </ins> } }, {

"constant" ], "settings": { <del> "foreground": "#AB6526" </del> <ins> "foreground": "#9C5D27" </ins> } }, {

"name": "Strings: Symbols", "scope": "constant.other.symbol", "settings": { <del> "foreground": "#AB6526" </del> <ins> "foreground": "#9C5D27" </ins> } }, {

"punctuation.definition.entity" ], "settings": { <del> "foreground": "#AB6526" </del> <ins> "foreground": "#9C5D27" </ins> } }, {

"support.type.property-name" ], "settings": { <del> "foreground": "#AB6526" </del> <ins> "foreground": "#9C5D27" </ins> } }, {

"scope": "markup.inline.raw", "settings": { "fontStyle": "", <del> "foreground": "#AB6526" </del> <ins> "foreground": "#9C5D27" </ins> } }, {
Change:
Have many items in an exclude scope (i.e. the vscode worksapce one). Have another scope default. The height for the exclude control gets calculated based on the number of items in the first control, and does not get updated when you switch to the next, until a recalculation is triggered by some other event. !

Discussion:
if (this.lastRenderedWidth !== width) { this.rowHeightCache = new Map<string, number>(); } <ins> this.longestSingleLineDescription = 0; </ins> this.lastRenderedWidth = width; } getHeight(tree: ITree, element: SettingsTreeElement): number { <del> if (this.rowHeightCache.has(element.id)) { </del> <ins> if (this.rowHeightCache.has(element.id) && !(element instanceof SettingsTreeSettingElement && isExcludeSetting(element.setting))) { </ins> return this.rowHeightCache.get(element.id); }
Change:
Take some setting, like , with a short description. Resize the window down until the description spans many lines. The description will now overflow onto the next setting. This is because the calculated estimate of max characters in a single line doesn't get updated on resize.

Discussion:
if (this.lastRenderedWidth !== width) { this.rowHeightCache = new Map<string, number>(); } <ins> this.longestSingleLineDescription = 0; </ins> this.lastRenderedWidth = width; } getHeight(tree: ITree, element: SettingsTreeElement): number { <del> if (this.rowHeightCache.has(element.id)) { </del> <ins> if (this.rowHeightCache.has(element.id) && !(element instanceof SettingsTreeSettingElement && isExcludeSetting(element.setting))) { </ins> return this.rowHeightCache.get(element.id); }
Change:
Has the selection color in the suggestion widget changed? I noticed that I several time picked the wrong suggestion since the currently selected item was difficult to see. Also notice currently selected item is shown in a different color than the currently selected item in a menu. The suggestion widget: ! The menu selection ! Notice that the menu selection is much more clear.
The color was updated to meet the color contrast ratio for when text is highlighted in the list: ! It also appears that the menu selection is using , which is typically used when needing to show both active selection and focus in a list: ! We could look at updating the color so that it's darker and allows more contrast between the selection (would also match the quick pick bg color): !

Discussion:
/** * Editor widgets */ <del> export const editorWidgetBackground = registerColor('editorWidget.background', { dark: '#2D2D30', light: '#EFEFF2', hc: '#0C141F' }, nls.localize('editorWidgetBackground', 'Background color of editor widgets, such as find/replace.')); </del> <ins> export const editorWidgetBackground = registerColor('editorWidget.background', { dark: '#252526', light: '#F3F3F3', hc: '#0C141F' }, nls.localize('editorWidgetBackground', 'Background color of editor widgets, such as find/replace.')); </ins> export const editorWidgetBorder = registerColor('editorWidget.border', { dark: '#454545', light: '#C8C8C8', hc: contrastBorder }, nls.localize('editorWidgetBorder', 'Border color of editor widgets. The color is only used if the widget chooses to have a border and if the color is not overridden by a widget.')); export const editorWidgetResizeBorder = registerColor('editorWidget.resizeBorder', { light: null, dark: null, hc: null }, nls.localize('editorWidgetResizeBorder', "Border color of the resize bar of editor widgets. The color is only used if the widget chooses to have a resize border and if the color is not overridden by a widget."));
Change:
Issue Id: <-96b3-ca5f-4d05-</b<br /<br /Versions <br /- <br /- <br /- <br /- <br /- <br /- <br /- <br /- <br /- <br /- <br /Stack <br /Error: Invalid start index: 1<br /)<br /<br /at <anonymous<br /at process._tickCallback (:188:7)<br /
this does not provide a lot of context, but became our number 2 top crash in error telemetry. Maybe we need to add more logging to get behind it?
This is an issue with the suggest widget.
has a good set of repro steps in using which I can repro the issue in Insiders but not in Stable 1.26.1 This is a case when an item from a list is selected, the list gets focus, and the corresponding event handler is called. If the event handler deals with promises, then by the time the promise is resolved, the list is gone. Should we probably have a way of identifying if the list got focus due to selection vs other cases?
I don't understand how the two things are related. If there is code which might access the list after it's been disposed, its caller should beware of this. It doesn't seem related to focus or selection at all.

Discussion:
this.currentSuggestionDetails = createCancelablePromise(token => item.resolve(token)); this.currentSuggestionDetails.then(() => { <ins> if (this.list.length < index) { return; } </ins> // item can have extra information, so re-render this.ignoreFocusEvents = true; this.list.splice(index, 1, [item]);
Change:
Issue Type: <bBug</b==<kbdCtrl</kbd+<kbdM</kbd<kbdTab</kbduntil get to tab (no pun intended) ! VS Code version: Code 1.26.1 (, 2018-08-16T18:38:57.434Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --

Discussion:
padding: 0; } <ins> .monaco-workbench > .part.editor > .content .editor-group-container > .title .tabs-container >  .tab.sizing-shrink:focus > .tab-label::after { opacity: 0; /* when tab has the focus this shade breaks the tab border (fixes https://github.com/Microsoft/vscode/issues/57819) */ } </ins> .monaco-workbench > .part.editor > .content .editor-group-container > .title .tabs-container > .tab.sizing-fit .monaco-icon-label, .monaco-workbench > .part.editor > .content .editor-group-container > .title .tabs-container > .tab.sizing-fit .monaco-icon-label > .monaco-icon-label-description-container { overflow: visible; /* fixes https://github.com/Microsoft/vscode/issues/20182 */

overflow: hidden; /* let the close button be pushed out of view when sizing is set to shrink to make more room... */ } <ins> .monaco-workbench > .part.editor > .content .editor-group-container > .title .tabs-container > .tab.close-button-right.sizing-shrink > .tab-close:focus-within { overflow: visible;/* fix invisible tab close button on focus: (fixes https://github.com/Microsoft/vscode/issues/41459) */ } </ins> .monaco-workbench > .part.editor > .content .editor-group-container > .title .tabs-container > .tab.dirty.close-button-right.sizing-shrink > .tab-close, .monaco-workbench > .part.editor > .content .editor-group-container > .title .tabs-container > .tab.close-button-right.sizing-shrink:hover > .tab-close { overflow: visible; /* ...but still show the close button on hover and when dirty */