jiebi/CodeConvo huggingface dataset:
Code change:
private layoutTree(): void { const scrollBarHeight = 10; <del> const treeHeight = Math.min(Math.max(266, this.editor.getLayoutInfo().height * 0.55), this.tree.contentHeight + scrollBarHeight); </del> <ins> let maxHeightToAvoidCursorOverlay = Infinity; if (this.showAtPosition) { const editorTop = this.editor.getDomNode()?.offsetTop || 0; const containerTop = this.treeContainer.offsetTop + editorTop; const hoveredCharTop = this.editor.getTopForLineNumber(this.showAtPosition.lineNumber, true) - this.editor.getScrollTop(); if (containerTop < hoveredCharTop) { maxHeightToAvoidCursorOverlay = hoveredCharTop + editorTop - 22; // 22 is monaco top padding https://github.com/microsoft/vscode/blob/a1df2d7319382d42f66ad7f411af01e4cc49c80a/src/vs/editor/browser/viewParts/contentWidgets/contentWidgets.ts#L364 } } const treeHeight = Math.min(Math.max(266, this.editor.getLayoutInfo().height * 0.55), this.tree.contentHeight + scrollBarHeight, maxHeightToAvoidCursorOverlay); </ins> const realTreeWidth = this.tree.contentWidth; const treeWidth = clamp(realTreeWidth, 400, 550);

Related discussion:
text: see gif have the debug hover above the cursor expand some objects the hover grows over the current line/cursor !
Yeah, this is a consequence of the change to not make it jump. Since in this scenario it does not have enough space above to grow, it can only grow over the line and below. Alternative would be to show it down, which would cause a jump. Or to limit the size, that it does not grow over the current line. That I think makes sense. However will not tackle during endgame.
How about not growing and use the scrollbar sooner? Just measure the max size above the cursor and don't go over that
I think this makes sense. My current max height is 70% of the editor height. Idealy as you suggest the max height should be the size above the cursor if I am placed above, or max size below the cursor if I am placed below. However I am not aware of editor API that gives me height above or below the cursor. Are you already using something like this for the suggest?
I am using and some math:
Code change:
"target" : { "classification": "SystemMetaData", "purpose": "FeatureInsight" } } */ <del> telemetryService.publicLog('update:win32SetupTarget', { target: product.target }); </del> <ins> this.telemetryService.publicLog('update:win32SetupTarget', { target: product.target }); </ins> } }

Related discussion:
text: run you'll notice that in the main process before creating the renderer the update service takes its time (~5-10ms). while that's not much it seems unnecessary and "block" the renderer for no good reason <img width="1101" alt="Screenshot 2020-01-31 at 14 45 07" src="https://user-"
This is only problematic in macOS where calls into the native which blocks.
Thanks
Code change:
"list.hoverBackground": "#F2F2F2", "list.focusAndSelectionOutline": "#005FB8", "menu.border": "#CECECE", <ins> "menu.selectionBackground": "#005FB8", "menu.selectionForeground": "#ffffff", </ins> "notebook.cellBorderColor": "#E5E5E5", "notebook.selectedCellBackground": "#C8DDF150", "notificationCenterHeader.background": "#FFFFFF",

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.85.2 OS Version: Windows 11 Enterprise (Windows_NT x64 10.0..3007) Description During an accessibility test, we found the contrast ratio between the highlight color of the focused button in "More Actions..." in notification popup and its background is not high enough under "Default Dark Modern" theme. Highlight Color: Background Color: Contrast Ratio: 1.346:1 Required Contrast Ratio: 3:1 !
I think this refers to the background color of the gear icon in the toolbar of a notification relative to the background color of the notification.
The bug reported on my side particularly specified the "Manage Extension" button highlight color and the background color of that actions popup under settings icon in the notification.
Looks like it's about the blue on black bg, in that case this applies to all the web menus in VS Code.
yes, it's about the blue highlight and black background.
A11yMAS; #A11yTCS; #A11ySev2; #DesktopApp; #Win32; #Visual Studio Code Client; #BM-VisualStudioCodeClient-Win32-Aug2023; #WCAG1.4.11; #Non-text Contrast;
Hi, is there any update on the plan of fixing this accessibility bug?
putting this on the March plan.
Hi, may I check if the fix is included in v1.88.0?
Hi, I have checked v1.88.0 but it seems the active color is still not the one you changed to in your PR. Did I miss something?
Code change:
"list.hoverBackground": "#F2F2F2", "list.focusAndSelectionOutline": "#005FB8", "menu.border": "#CECECE", <ins> "menu.selectionBackground": "#005FB8", "menu.selectionForeground": "#ffffff", </ins> "notebook.cellBorderColor": "#E5E5E5", "notebook.selectedCellBackground": "#C8DDF150", "notificationCenterHeader.background": "#FFFFFF",

Related discussion:
text: Verified with the Dark Modern theme, but do we also have to fix this with the Dark+ or Dark (Visual Studio) themes?
Thanks, I think it's fine we only fix it in default dark theme for now. The test team doesn't require that in other themes so far.
Code change:
this.update(); } <ins> get toggles() { return this._toggles; } set toggles(toggles: IQuickInputToggle[]) { this._toggles = toggles ?? []; this.togglesUpdated = true; this.update(); } </ins> get validationMessage() { return this._validationMessage; }

Related discussion:
text: Type: <bBug</bFuzzy search icon is visible in Go to Symbol view (Shift + CMD + O) which on press opens terminal recent search with fuzzy search. I think that button should be excluded from Go to Symbol view and be visible only in terminal recent search view. VS Code version: Code 1.73.1 (, 2022-11-09T02:22:48.959Z) OS version: Darwin arm64 22.1.0 <img width="607" alt="image" src="https://user-"<img width="597" alt="image" src="https://user-"<!-- generated by issue reporter --
Seems like after the icon is not cleared and shows up in any command palette entry
Code change:
if (typeof options?.focusEditorLine === 'number') { this._cursorNavMode.set(true); this.revealInView(cell); <del> } else if (options?.revealBehavior === ScrollToRevealBehavior.fullCell) { this.revealInView(cell); </del> } else if (options?.revealBehavior === ScrollToRevealBehavior.firstLine) { this.revealFirstLineIfOutsideViewport(cell); } else {

Related discussion:
text: a notebook that has several cells, and put this code in the second to last cell the cell so that it has output, and shrink the window so that the single cell+output takes up the whole scrollable region the cell again with shift+enter :bug: the notebook ends up scrolling up, instead of showing the full output and next cell. !
The current behavior of the list view is to use the second visible element as an anchor which can cause some strange behavior. In this scenario: next cell is focused and revealed, making that cell the anchor as second visible, since the executing cell takes up the rest of the visible region. output is removed, moving more elements into view from above is and the initial anchor is no longer the second element, so it is scrolled out of view I'll try to play around with some options, but my initial thought would be to use the executing cell as the anchor. The output could expand and push the next cell out of view, but typing in that cell will bring it back into view. cc
I wanted to see the behavior locally. I really can't seem to repro this, my notebook stays pretty stable as the cell shrinks and grows. What am I missing?
I think I found it. I believe you have disabled, am I correct? Can you reproduce this when flipping that setting back to the default value of ?
It repro's with or without - you just need to scroll down enough so that the resized cell is only partially visible. The strange behavior is due to the notebook cell list setting different anchors depending on whether the element top is above the render top.
As I looked into the remaining open issue and PR , I was trying to grasp what the issue really is, what has been actually fixed and what's left to fix. Then, I pulled latest and ran out of sources and this is even worse than my last recording. Everything jumps around even when the cell is fully in view: Did just break this even more? I suggest reverting , pausing, simplifying the problem, narrowing in on a solution and consider fixing it in debt week so as to not cause regressions during this endgame week. cc
thanks for the testing, the two recordings you posted above were using different execution commands so I want to ensure we refer to the same behavior: in , it's re-executing the active cell (ctrl+enter), which should always stay visually stable.
Code change:
if (typeof options?.focusEditorLine === 'number') { this._cursorNavMode.set(true); this.revealInView(cell); <del> } else if (options?.revealBehavior === ScrollToRevealBehavior.fullCell) { this.revealInView(cell); </del> } else if (options?.revealBehavior === ScrollToRevealBehavior.firstLine) { this.revealFirstLineIfOutsideViewport(cell); } else {

Related discussion:
text: I think it still works this way out from source in the latest , from what I saw, it's running shift+enter: run cell and move to next This command moves focus to the next cell, so the cell is now the focused cell Then the output of the previous cell (which is no longer focused) starts to grow The change introduced via 's last PR was to ensure that the focused cell stay visually stable, once they are revealed into view can you confirm if this is what you are seeing?
I captured a recording for what probably was comparing, right side is Stable and left side Insiders In both setup, the next cell is fully visible In Stable, shift+enter moves the next cell up, and then push it down, but the new focused cell is still visible in the viewport at the end In Insiders, shift+enter moves the next cell up, and when the previous starts to grow, it does not move the focused cell downwards Even though the new behavior is more self explanatory (from our perspective), but unluckily is not the same as Jupyter Lab. It means we are changing from one custom behavior (our previous heuristics) to another (always keep focused cell stable)
Thanks for clarifying this It was not clear to me that (1) shift+enter and clicking the run cell action did different things, nor that (2) this bug was only about one of these actions.
fixed by
Code change:
if (typeof options?.focusEditorLine === 'number') { this._cursorNavMode.set(true); this.revealInView(cell); <del> } else if (options?.revealBehavior === ScrollToRevealBehavior.fullCell) { this.revealInView(cell); </del> } else if (options?.revealBehavior === ScrollToRevealBehavior.firstLine) { this.revealFirstLineIfOutsideViewport(cell); } else {

Related discussion:
text: Currently the scroll top position update is not context-aware, meaning when we have cell height changes, we don't know if it's because output height change, or users re-run a cell and outputs are updated/replaced, or users shift+enter to run cell and navigate to next cell. Users might have different expectations for each scenario but currently our heuristics for updating the scroll top didn't take the context into account. Let's use this issue to finalize the desired behavior of scroll top update. The polished/new design should cover [ ] Update element height API respects context (execution, execute+create, output update) [ ] Reveal API should handle out of sync view/content height Click the run button or press Ctrl+Enter to run focused cell If there is no enough room/space after the cell (e.g., the focused cell is the last cell) Users have disabled [ ] There is no output before execution, the view should scroll up to reveal the output fully [ ] Some users might want the bottom of the output to be fully revealed, when the output is larger than the viewport [ ] There is output before execution, the cell position should be persistent Users have enabled [ ] Reveal cell output If there is enough room after the cell [ ] Reveal cell output [ ] If the cell input is larger than the viewport, execute cell should reveal the output properly [ ] Collapse focused cell output should always keep the cell in viewport [ ] Type/Pasting content into focused cell should keep the cell in viewport [x] [ ] Notebook cell list reveal api might reveal a position on a cell whose view height is not synced with real editor height yet. [ ] Execute non-focused cell, should it keep the focused cell position persistent or keep the top of the target cell persistent? [ ] Non focused cell output height change should not change scroll top on scroll [ ] Shift+enter executes and moves focus to next cell, then new focused cell should always be in viewport [x] Scroll top position of inactive notebook editor should not change if the first partially visible cell's height change
I noticed an issue recently, is this related? Paste a large amount of text into a code cell The notebook scrolls down so far that the focused code cell is out of the viewport I can open a separate issue if you want
I guess what you were seeing is , I'll update the description to include this.
Couple cases discovered in the latest notebook sync.
Code change:
if (typeof options?.focusEditorLine === 'number') { this._cursorNavMode.set(true); this.revealInView(cell); <del> } else if (options?.revealBehavior === ScrollToRevealBehavior.fullCell) { this.revealInView(cell); </del> } else if (options?.revealBehavior === ScrollToRevealBehavior.firstLine) { this.revealFirstLineIfOutsideViewport(cell); } else {

Related discussion:
text: both of these are likely tied to outputLineLimit being large @ 100 when the shift-enter behavior is set to "firstline" the events are as follows: first line of next cell is focused and shown at the bottom of the viewport output is cleared and the focused cell is pulled upwards against the currently executing cell output streams and pushes the focused cell out of the viewport. my ideal thoughts: anchor the focused cell (with setting), maintaining the first line visible. output will stream in, pushing the executing cell upwards out of the viewport shift-enter set to "fullCell" and next cell has a large output focus shifts to next cell, and the viewport exposes the bottom of the output for that cell. there is no cell editor in the viewport my thoughts: "fullCell" behavior should show the top of the next cell editor at the top of the viewport
Code change:
"displayName": "Markdown it ipynb Cell Attachment renderer", "entrypoint": { "extends": "vscode.markdown-it-renderer", <del> "path": "./out/cellAttachmentRenderer.js" </del> <ins> "path": "./notebook-out/cellAttachmentRenderer.js" </ins> } } ],

Related discussion:
text: Type: <bBug</bipynb notebook bug In dev tools, see: VS Code version: Code - Insiders 1.70.0-insider (Universal) (, 2022-07-26T05:17:37.262Z) OS version: Darwin x64 21.5.0 Modes: <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Looks like the directory is excluded from publish: You likely want to have the notebook code go to a different directory, such as instead of the dir
Just changed that inside esbuild, didn't realize that out wasn't included. I had been having an issue with needing to run while using OSS, could that be related? I'll make a PR to adjust and
Code change:
// Meta if (element.saneDetail) { <ins> data.detail.element.style.display = ''; </ins> data.detail.setLabel(element.saneDetail, undefined, { matches: detailHighlights, title: element.saneDetail }); <del> } /* else { // TODO investigate potential detail bleeding into next quickpicks data.detail.setLabel(''); } */ </del> <ins> } else { data.detail.element.style.display = 'none'; } </ins> // Separator if (element.item && element.separator && element.separator.label) {

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: 1.73.1 OS Version: macOS Ventura 13.0.1 Steps to Reproduce: VoiceOver a command that uses a Quick Pick List where the items have a as well as a title or description (demoed with Azure Extension "Create Resource") list a command that uses a Quick Pick List where the items have no detail, e.g. "Select Display Language" or even command palette reader will read the title of the new item with the detail of the item in the previously displayed quick pick list https://user- Same bug with the command palette reading details for items: https://user-
This issue is caused by the item still containing the values from the previous list.
Verification steps: the issue steps are good. If you want a non-Azure extension command that shows a quick pick with details, use
Code change:
} fs.writeFileSync(this.workspacesJsonPath, JSON.stringify(this.backups)); } catch (ex) { <del> console.error('Could not save workspaces.json', ex); </del> <ins> console.error(`Backup: Could not save workspaces.json: ${ex.toString()}`); </ins> } }

Related discussion:
text: Moving this over from After the backups are not restored if the workspace directory doesn't exist anymore. The workspace is no longer tracked but the backups are kept around in the backup directory should they be needed later.
Tricky.... I would expect an empty window to open with those files dirty. This might require some work on the area of restoring on empty workspaces. Have not thought about this longer yet.
Marking as important because this means data loss if the folder is deleted on disk.
maybe this should be done on the main side on startup similarly to If a folder no longer exists, convert it into an empty workspace backup and let it open as empty window.
On test plan:
Code change:
import { IContextKeyService, IContextKey } from 'vs/platform/contextkey/common/contextkey'; import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding'; import { IPanelService } from 'vs/workbench/services/panel/common/panelService'; <del> import { ITerminalInstance, KEYBINDING_CONTEXT_TERMINAL_TEXT_SELECTED, TERMINAL_PANEL_ID, IShellLaunchConfig, ITerminalProcessManager, ProcessState } from 'vs/workbench/parts/terminal/common/terminal'; </del> <ins> import { ITerminalInstance, KEYBINDING_CONTEXT_TERMINAL_TEXT_SELECTED, TERMINAL_PANEL_ID, IShellLaunchConfig, ITerminalProcessManager, ProcessState, NEVER_MEASURE_RENDER_TIME_STORAGE_KEY } from 'vs/workbench/parts/terminal/common/terminal'; </ins> import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { StandardKeyboardEvent } from 'vs/base/browser/keyboardEvent'; import { TabFocus } from 'vs/editor/common/config/commonEditorConfig';

Related discussion:
text: Upstream:
It's not true that it takes very long. It does not get visible at all. I have to downsize the terminal pane to a certain size to make it visible again. In my case it's about 5-10 lines. Seems to me that the canvas is not resized properly. There are no problems if I disable GPU rendering (code --disable-gpu). Also without any noticeable performance issues. Would be nice to have a flag in the preferences to disable GPU rendering as a quick workaround. One of the reasons for using code (instead of Atom or Sublime) was the integrated terminal which seems to be broken since the new canvas rendering was introduced. My System Config: OS X 10.11.6, GPU: NVidia 8800, 4GB RAM
that will probably get fixed as part of this as well, it's probably something to do with your GPU/Chromium not liking the texture sizes above a certain size.
Code change:
}); viewsRegistry.registerViewWelcomeContent(WelcomeView.ID, { <del> content: localize( { key: 'detectThenRunAndDebug', comment: [ 'Please do not translate the word "command", it is part of our internal syntax which must not change', '{Locked="](command:{0})"}', ] }, "[Show all automatic debug configurations](command:{0}).", SELECT_AND_START_ID), </del> <ins> content: `[${localize('detectThenRunAndDebug', "Show all automatic debug configurations")}](command:${SELECT_AND_START_ID}).`, </ins> when: CONTEXT_DEBUGGERS_AVAILABLE, group: ViewContentGroups.Debug, order: 10

Related discussion:
text: There's an unnecessary whitespace in "i18n/vscode-language-pack-". The whitespace after "command:" makes the link dead. !
you can add a comment to this string like so: to ensure that the command never has a problem like this. Notice that the example string has, in the Locked area, a at the start of it. This will make sure there is no whitespace between them.
Code change:
.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; }

Related discussion:
text: 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