Question: override updateOptions(options: IWorkbenchDataTreeOptionsUpdate = {}): void { super.updateOptions(options); <del> if (options.overrideStyles) { </del> <ins> if (options.overrideStyles !== undefined) { </ins> this.internals.updateStyleOverrides(options.overrideStyles); }

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.


Question: await this._stageChanges(textEditor, [changes[index]]); <del> const firstStagedLine = changes[index].modifiedStartLineNumber - 1; </del> <ins> const firstStagedLine = changes[index].modifiedStartLineNumber; </ins> textEditor.selections = [new Selection(firstStagedLine, 0, firstStagedLine, 0)]; }

<!-- 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.71.0 (user setup) OS Version: Windows_NT x64 10.0. Git Version: 2.30.2 (Windows) Steps to Reproduce: a new directory a new Git repository a new file and append some text on the first lines this file to the staging the line with text An OS native dialog box error pops up with the title of this issue as text. In the console output for Git: I have had this problem for a long time, 2 years I would say. I thought someone would have reported it but it seems not.
I'm having a similar issue on macOS 12.6 (21G115). If you have deleted lines at the top of a file and click the little arrow to undo the change, the error pops up. Notably, it still completes the undo. <img width="396" alt="image" src="https://user-"
apologies for not getting back to you on this. I used the repro steps above but I was unable to reproduce the problem with the latest VS Code Insiders (1.75) release. Could you please do me a favour and see if you are still able to reproduce the issue? If so, could you please share a recording using so that I can further investigate the issue? Thanks!
Issue is still present in the latest insider release on macOS. !


Question: await this._stageChanges(textEditor, [changes[index]]); <del> const firstStagedLine = changes[index].modifiedStartLineNumber - 1; </del> <ins> const firstStagedLine = changes[index].modifiedStartLineNumber; </ins> textEditor.selections = [new Selection(firstStagedLine, 0, firstStagedLine, 0)]; }

VSCode info: Version: 1.75.0-insider Commit: Date: 2022-12-19T05:35:41.089Z (10 hrs ago) Electron: 19.1.8 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Darwin arm64 21.6.0 Sandboxed: Yes


Question: } const config = workspace.getConfiguration('git', Uri.file(this.repository.root)); <del> const fetchBeforeCheckout = config.get<boolean>('fetchBeforeCheckout', false) === true; </del> <ins> const pullBeforeCheckout = config.get<boolean>('pullBeforeCheckout', false) === true; </ins> <del> if (fetchBeforeCheckout) { </del> <ins> if (pullBeforeCheckout) { </ins> await this.repository.fastForwardBranch(this.ref.name!); }

Testing The feature is called . But it does more than fetch, it also pulls. Fetch typically only 'downloads' commits, but does not update any branches. Maybe the proper name would be:


Question: export function keybindingForAction(id: string): Keybinding { switch (id) { <del> case GlobalNewFileAction.ID: </del> <ins> case GlobalNewUntitledFileAction.ID: </ins> return new Keybinding(KeyMod.CtrlCmd | KeyCode.KEY_N); case TriggerRenameFileAction.ID: return new Keybinding(isMacintosh ? KeyCode.Enter : KeyCode.F2);

VSCode Version: 1.0.0 OS Version: OSX 10.11.3 I noticed that we can set to a keybinding. Which creates a nice input field in the sidebar to create the directory at the current selected position. ! But there is no possibility to do this for a file. Yes you can bind but it does not do the same thing. It just creates a new and when pressing <kbdcmd</kbd+ <kbds</kbdyou have to choose the destination in a picker. So, is it possible to add something for a new file as well? It would really improve my speed because I don't have to touch my mouse anymore to create a new named file in a specific directory.
sounds like a good example for a PR?
Yes I looked into it but to be honest, I have to clue where to start :). So if you can point me in the right direction, I would be very happy to do one :).
I would start by fulltext search for the action id () and that brings you here: From there you can get a feeling how this global action works and maybe add the new one. You will also see the one on top for creating an untitled file (which is not what you want). When you find the references of that action you will see where it is being registered to the system:
Alright, awesome. Thank you very much Will see what I can do :).


Question: } .merge-editor-block:not(.handled):not(.focused) { <del> border: 1px dashed var(--vscode-mergeEditor-conflict-unhandledUnfocused-border); </del> <ins> border: 1px solid var(--vscode-mergeEditor-conflict-unhandledUnfocused-border); </ins> } .merge-editor-block:not(.handled).focused { <del> border: 1px dashed var(--vscode-mergeEditor-conflict-unhandledFocused-border); </del> <ins> border: 1px solid var(--vscode-mergeEditor-conflict-unhandledFocused-border); </ins> } .merge-editor-block.handled:not(.focused) {

! The highlighting is important to understand which conflict in the bottom view corresponds to which conflicts in result. I think the change of the color of the dashed border is difficult to notice.


Question: collapseByDefault: true, expandOnlyOnTwistieClick: true, multipleSelectionSupport: false, <ins> showNotFoundMessage: false </ins> } ); }

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.


Question: collapseByDefault: true, expandOnlyOnTwistieClick: true, multipleSelectionSupport: false, <ins> showNotFoundMessage: false </ins> } ); }

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. !


Question: return this.sendAllBreakpoints(); } <del> addBreakpoints(uri: uri, rawBreakpoints: IBreakpointData[]): TPromise<IBreakpoint[]> { </del> <ins> addBreakpoints(uri: uri, rawBreakpoints: IBreakpointData[], context: string): TPromise<IBreakpoint[]> { </ins> const breakpoints = this.model.addBreakpoints(uri, rawBreakpoints); breakpoints.forEach(bp => aria.status(nls.localize('breakpointAdded', "Added breakpoint, line {0}, file {1}", bp.lineNumber, uri.fsPath))); <ins> breakpoints.forEach(bp => this.telemetryDebugAddBreakpoint(bp, context)); </ins> return this.sendBreakpoints(uri).then(() => breakpoints); }

When going over our telemetry for debug actions we have the ability to track usage counts of debug actions triggered from keyboard shortcuts and commands, as they execute commands which we emit telemetry for, but we don't seem to have telemetry in place for breakpoints set in the gutter (click or context menu). This is unfortunate as my hypothesis is that the majority of breakpoints are set this way. Ask Add ability to track breakpoint toggles (add/remove/change) from Gutter click Add ability to track breakpoint toggles from gutter context menu
would you like to contribute a PR for this? It shuold be fairly simple and you already have the nice code pointers.
I'd be happy too, but we should land on an agreement on how to implement it. What's the best approach? 1) Add telemetry directly to the gutter actions 2) Re-wire the gutter actions to execute a command instead?
for the best approach let's first see what you want to get exactly? total amount of all breakpoints set (including the gutter) grained events for breakpoint setting based on the way the user initated that aciton In case of 1 we should just add a telemetry ping in the  since everyone should go through there In case of 2 depends on how fine grained you want it, if for every place then we should add an argument or something like that in the addBreakpoints method and then also report that to telemetry.
I'd like us to be able to contribute a source/initiator to given breakpoint, so we can get an UI usage distributions, etc.
I suggest the following Add a third argument In the implementation of that method use the telemetry service to report the appropriate event with the context. And you should nicely get all the errors of all the callers of , simply pass different string context for each caller and you shuold be good to go. Let me know if you have any questions
Cool, I'l see what I can get cooking!
Removing my assignment for this. feel free to assign me back if you do not have time to tackle this and if we need this for August
hey, would you still like this? If yes I can also look into it in October
I'd still like to do this to get my hands dirty.
cool, unasigning myself and let's leave it for October
Verified by code review, adding verified label


Question: export const listInactiveFocusOutline = registerColor('list.inactiveFocusOutline', { dark: null, light: null, hc: null }, nls.localize('listInactiveFocusOutline', "List/Tree outline color for the focused item when the list/tree is inactive. An active list/tree has keyboard focus, an inactive does not.")); export const listHoverBackground = registerColor('list.hoverBackground', { dark: '#2A2D2E', light: '#F0F0F0', hc: null }, nls.localize('listHoverBackground', "List/Tree background when hovering over items using the mouse.")); export const listHoverForeground = registerColor('list.hoverForeground', { dark: null, light: null, hc: null }, nls.localize('listHoverForeground', "List/Tree foreground when hovering over items using the mouse.")); <del> export const listDropBackground = registerColor('list.dropBackground', { dark: listFocusBackground, light: listFocusBackground, hc: null }, nls.localize('listDropBackground', "List/Tree drag and drop background when moving items around using the mouse.")); </del> <ins> export const listDropBackground = registerColor('list.dropBackground', { dark: '#062F4A', light: '#D6EBFF', hc: null }, nls.localize('listDropBackground', "List/Tree drag and drop background when moving items around using the mouse.")); </ins> export const listHighlightForeground = registerColor('list.highlightForeground', { dark: '#0097fb', light: '#0066BF', hc: focusBorder }, nls.localize('highlight', 'List/Tree foreground color of the match highlights when searching inside the list/tree.')); export const listInvalidItemForeground = registerColor('list.invalidItemForeground', { dark: '#B89500', light: '#B89500', hc: '#B89500' }, nls.localize('invalidItemForeground', 'List/Tree foreground color for invalid items, for example an unresolved root in explorer.')); export const listErrorForeground = registerColor('list.errorForeground', { dark: '#F88070', light: '#B01011', hc: null }, nls.localize('listErrorForeground', 'Foreground color of list items containing errors.'));

There is no drop hover feedback in the Explorer, for example, when in Light+ theme.
Broken by:


Question: "@vscode/windows-mutex": "^0.5.0", "@vscode/windows-process-tree": "^0.6.0", "@vscode/windows-registry": "^1.1.0", <del> "@xterm/addon-clipboard": "0.2.0-beta.39", "@xterm/addon-image": "0.9.0-beta.56", "@xterm/addon-search": "0.16.0-beta.56", "@xterm/addon-serialize": "0.14.0-beta.56", "@xterm/addon-unicode11": "0.9.0-beta.56", "@xterm/addon-webgl": "0.19.0-beta.56", "@xterm/headless": "5.6.0-beta.56", "@xterm/xterm": "5.6.0-beta.56", </del> <ins> "@xterm/addon-clipboard": "^0.2.0-beta.47", "@xterm/addon-image": "^0.9.0-beta.64", "@xterm/addon-search": "^0.16.0-beta.64", "@xterm/addon-serialize": "^0.14.0-beta.64", "@xterm/addon-unicode11": "^0.9.0-beta.64", "@xterm/addon-webgl": "^0.19.0-beta.64", "@xterm/headless": "^5.6.0-beta.64", "@xterm/xterm": "^5.6.0-beta.64", </ins> "http-proxy-agent": "^7.0.0", "https-proxy-agent": "^7.0.2", "jschardet": "3.1.3",

<!-- 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. After updating to VS Code 1.92, I noticed several scroll-related issues with the integrated terminal: exiting a full screen CLI app ( or ), sometimes scroll up or down doesn't work anymore until I press cmd+c - at which point I am teleported back to the start of the cli log. See the below video: start scroll works (though way too sensitive - see issue 2) press scroll up down no longer works press as soon as I try to scroll again, I am teleported to the top of the cli log output (though, at least scroll works after that)Note, while the above triggers the issue, sometimes the issue also occurs even without that (at one point I just run and this bug was triggered) full-screen CLI apps (, , ), the scroll sensitivity is way higher than when scrolling in non-full-screen apps. This scroll sensitivity is uncomfortably high, way higher than it was before, and remains high even if I set to a very low value like 0.1. scrolling through full-screen CLI app ( or ), sometimes the terminal will not let me scroll up. If I try to scroll up, I am "teleported" back to previous position. As soon as I scroll down, I can't scroll back up to the previous text. <!-- 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. --Relevant information: VS Code Version: 1.92 OS Version: macOS 14.5 Issues are reproducible in ZSH.


Question: "@vscode/windows-mutex": "^0.5.0", "@vscode/windows-process-tree": "^0.6.0", "@vscode/windows-registry": "^1.1.0", <del> "@xterm/addon-clipboard": "0.2.0-beta.39", "@xterm/addon-image": "0.9.0-beta.56", "@xterm/addon-search": "0.16.0-beta.56", "@xterm/addon-serialize": "0.14.0-beta.56", "@xterm/addon-unicode11": "0.9.0-beta.56", "@xterm/addon-webgl": "0.19.0-beta.56", "@xterm/headless": "5.6.0-beta.56", "@xterm/xterm": "5.6.0-beta.56", </del> <ins> "@xterm/addon-clipboard": "^0.2.0-beta.47", "@xterm/addon-image": "^0.9.0-beta.64", "@xterm/addon-search": "^0.16.0-beta.64", "@xterm/addon-serialize": "^0.14.0-beta.64", "@xterm/addon-unicode11": "^0.9.0-beta.64", "@xterm/addon-webgl": "^0.19.0-beta.64", "@xterm/headless": "^5.6.0-beta.64", "@xterm/xterm": "^5.6.0-beta.64", </ins> "http-proxy-agent": "^7.0.0", "https-proxy-agent": "^7.0.2", "jschardet": "3.1.3",

I was also able to trigger issue 1 in BASH In ZSH, I am using oh-my-zsh and powerlevel19k, BUT I was able to reproduce the issues even after I temporary disabled oh-my-zsh and powerlevel19k in my Issues are reproducible even if I start VS Code with empty user dir and empty extensions dir. A few relevant settings: is off. Enabling it does not make things better N/A as I am not holding the key - I am just scrolling using the touchpad is off. Enabling it did not make things better I am sorry if some of the above reproduction steps a bit vague - some of these don't happen each time so it's hard to see what triggered it. But these all started happening as soon as VS Code got updated to 1.92. I will keep updating this issue if I have more details. <details<summarySystem info</summaryGeneral: System info: System Information | -- | -- CPUs | Apple M1 Pro (10 x 2400) GPU Status | 2dcanvas: enabled canvasooprasterization: enabledon directrenderingdisplaycompositor: disabledoffok gpucompositing: enabled multiplerasterthreads: enabledon opengl: enabledon rasterization: enabled rawdraw: disabledoffok skiagraphite: disabledoff videodecode: enabled videoencode: enabled webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off Load (avg) | 2, 2, 3 Memory (System) | 32.00GB (6.06GB free) Process Argv | /Users/mak13180/site/esri/arcgis-web-components --crash-reporter-id -0746-4857-a17b- Screen Reader | no VM | 0% Enabled extensions (BUT, issues are reproducible with all extensions disabled): Extension Version -- -- vite 0.2.5 shell-syntax 1.0.5 vscode-tailwindcss 0.12.5 vscode-eslint 3.0.10 apc-extension 0.4.1 gitlens 15.2.3 vscode-html-css 2.0.10 prettier-vscode 10.4.0 lintlens 7.5.0 copilot 1.219.0 copilot-chat 0.18.1 vscode-github-actions 0.26.


Question: "@vscode/windows-mutex": "^0.5.0", "@vscode/windows-process-tree": "^0.6.0", "@vscode/windows-registry": "^1.1.0", <del> "@xterm/addon-clipboard": "0.2.0-beta.39", "@xterm/addon-image": "0.9.0-beta.56", "@xterm/addon-search": "0.16.0-beta.56", "@xterm/addon-serialize": "0.14.0-beta.56", "@xterm/addon-unicode11": "0.9.0-beta.56", "@xterm/addon-webgl": "0.19.0-beta.56", "@xterm/headless": "5.6.0-beta.56", "@xterm/xterm": "5.6.0-beta.56", </del> <ins> "@xterm/addon-clipboard": "^0.2.0-beta.47", "@xterm/addon-image": "^0.9.0-beta.64", "@xterm/addon-search": "^0.16.0-beta.64", "@xterm/addon-serialize": "^0.14.0-beta.64", "@xterm/addon-unicode11": "^0.9.0-beta.64", "@xterm/addon-webgl": "^0.19.0-beta.64", "@xterm/headless": "^5.6.0-beta.64", "@xterm/xterm": "^5.6.0-beta.64", </ins> "http-proxy-agent": "^7.0.0", "https-proxy-agent": "^7.0.2", "jschardet": "3.1.3",

3 vscode-pull-request-github 0.92.0 gc-excelviewer 4.2.59 todo-tree 0.0.226 search-node-modules 1.3.0 nodejs-repl 0.5.15 rainbow-csv 3.12.0 remote-ssh 0.112.0 remote-ssh-edit 0.86.0 remote-explorer 0.4.3 vscode-css-peek 4.4.1 vscode-yaml 1.15.0 code-spell-checker 3.0.1 vscode-stylelint 1.4.0 vscode-mdx 1.8.9 vscodeintellicode 1.3.1 explorer 1.0.6 vim 1.27.3 pretty-ts-errors 0.6.0 markdown-all-in-one 3.6.2 A/B experiment info: My (BUT, issues are also reproducible when VS Code is started with empty user dir): The log when VS Code is started as : </details
Upstream PR fixing it


Question: import { ContextScopedFindInput } from 'vs/platform/history/browser/contextScopedHistoryWidget'; import { widgetClose } from 'vs/platform/theme/common/iconRegistry'; import * as strings from 'vs/base/common/strings'; <del> import { TerminalCommandId } from 'vs/workbench/contrib/terminal/common/terminal'; </del> import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding'; import { showHistoryKeybindingHint } from 'vs/platform/history/browser/historyWidgetKeybindingHint'; import { status } from 'vs/base/browser/ui/aria/aria';

Terminal: <img width="328" alt="image" src=""Editor: <img width="436" alt="image" src=""


Question: import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding'; import { AccessibilityVerbositySettingId, accessibilityHelpIsShown, accessibleViewIsShown } from 'vs/workbench/contrib/accessibility/browser/accessibilityConfiguration'; import { ILayoutService } from 'vs/platform/layout/browser/layoutService'; <del> import { Action2, MenuId } from 'vs/platform/actions/common/actions'; </del> <ins> import { Action2, MenuId, registerAction2 } from 'vs/platform/actions/common/actions'; </ins> import { KeybindingWeight } from 'vs/platform/keybinding/common/keybindingsRegistry';

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


Question: this._resourceContentProvider.deleteAndDispose(handle); } <del> $onVirtualDocumentChange(uri: UriComponents, value: string): void { </del> <ins> async $onVirtualDocumentChange(uri: UriComponents, value: string): Promise<void> { </ins> const model = this._modelService.getModel(URI.revive(uri)); if (!model) { return;

Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.77.2 OS Version: Windows 10 It seems that when refreshing () the in a short period, the second refresh is not actually performed. I have provided an example repo and a video demonstrating the issue. Basically we have a that shadows the active editor so whenever a user changes the active editor we update the read only document. However, if the user changes the editors quickly enough then the second change is dropped... Steps to Reproduce: the extension the command "Open Read Only Document" tabs quickly and see how it falls behind even though the content is up to date https://user- The content is actually set but it seems the second is dropped. Because if you refresh the document manually it shows the correct content (see the video above). The issue seems to happen more frequently if the content of the file(s) is large.
I found out why it happens and attempted a fix (with explanation) in
Pinging so it does not get lost


Question: label?: string; /** <ins> * The optional state of a comment thread, which may affect how the comment is displayed. */ state?: CommentThreadState; /** </ins> * Dispose this comment thread. * * Once disposed, this comment thread will be removed from visible editors and Comment Panel when appropriate.

<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --The comments API doesn't have the concept of resolved/unresolved threads, although most code review tools distinguish them. The current API allows us to surface this to the users, see However, this seems pretty limited. I find it difficult to identify all my unresolved comments. It's very easy to miss some of them. If the API had a boolean for unresolved comments, we could surface them in multiple ways: In the Comments panel, surface the number of unresolved comments, similar to what is done with Problems: ! In the Comments panel, highlight the unresolved comments (or put them in bold), so that it's obvious to the user what comments they still have to go through. In the Comments panel, have a way to hide/filter the resolved comments. In the Editor, consider consider using a different background color for unresolved comments. I currently use a different label for unresolved comments, but this is very subtle. In the gutter, use a different symbol for unresolved comments (e.g. or a diamond of another color). In the Editor, provide a way to go to the next unresolved comment (an alternative to ).
Let's discuss the API change. IMO, the information should be part of a . On many levels, Comments seem similar to s. A diagnostic is a comment provided by a tool such as a compiler. A comment is typically provided by a human. Diagnostics have a severity field, which indicates how important is the problem. We need an equivalent for Comments, something that tells the user if an action is expected (e.g. they need to resolve it) or not. Once the user addresses the comment, the importance is reduced. simplistic solution is to add a boolean, e.g. . to , we can go for a two-state enum instead: to be more general: . We might consider having more fields here. In a code review, multiple users interact with the comments. The current VSCode user is not necessarily the person who needs to do something. For example, the user has just updated the comment and they wait for a response.


Question: label?: string; /** <ins> * The optional state of a comment thread, which may affect how the comment is displayed. */ state?: CommentThreadState; /** </ins> * Dispose this comment thread. * * Once disposed, this comment thread will be removed from visible editors and Comment Panel when appropriate.

So the third value could be used to mean "it's not my turn" or "acknowledged, I'll come back later". The benefit is that the user can use the list of "unresolved" issues as a TODO-list and publish the comments once it's empty.
Thank you very much for your proposal. and me have quickly discussed this and we believe this proposal makes good sense. We plan to start looking into it next milestone. Though no promises yet when this will land, we will know more in December when we start our investigation.
All of the proposals in have merit. In a perfect world I would choose one of options 2 or 4; however, we have users of the comments API who's comments don't have a resolved/unresolved state. Option 3 circumvents that, but then we have the issue of what to show in the UI: a GitHub PR comment isn't high or low priority. Another proposal, similar to how comment reactions work:
I see than left comments on the commit (). I like the approach of having an object for the state (instead of the proposed boolean/enum), it gives more flexibility and lets user create their own states. In my proposal, the information was attached to a thread, not to a single comment. Do we have use-cases where we want this information per comment? We might also want to control the gutter icon:
GitHub comments are resolved per-thread, so no, no cases were we want it per comment. I'll move it to the thread.
After much discussion, we have decided to proceed with the following: The main reasoning behind this is that resolved vs. unresolved comments should look the same to the user across a GitHub PR extension, an Azure Dev Ops PR extensions, and any other PR extension. There original concern around using "resolved" and "unresolved" is that maybe not all comment provider have those states (maybe they have "viewed" and "unviewed" states for example). To alleviate this, we'll see if we can avoid using "resolved"/"unresolved" language in the UI. If additional states are needed later, we can always add more to the API.
I have a basic implementation of this working, with and themable colors. Before I finish up the pull request to send it out, I was wondering what the best practice is for providing defaults for these colors?


Question: label?: string; /** <ins> * The optional state of a comment thread, which may affect how the comment is displayed. */ state?: CommentThreadState; /** </ins> * Dispose this comment thread. * * Once disposed, this comment thread will be removed from visible editors and Comment Panel when appropriate.

In the mocks from we use a yellow for unresolved comments that is inspired by visuals of our internal tool. I am not sure if they match an established VS Code palette.
awesome, looking forward to reviewing it! Generally, we try to avoid introducing a new color entirely for something like this. The best practice would be to look through the existing color values where we use yellow then use the same yellow, just like is done here where uses the same color as : We'll also do a UX review of this, so the color may end up changing anyway.
I went for new colors as the comments are conceptually something different than e.g. editor warnings. Currently the comments in the editor use (default blue), so a theme, an extension, or the users themselves would not be able to style comments independently of peek views. I think it makes sense to base the default on another color like as in your example, so that themes which omit the new colors receive a reasonable default, but it seems like we would give up a lot of flexibility and also clarity if comment widget colors directly used something like internally?
Yes, basing the color on another is what I meant! I agree that we don't want to directly use another theme color.
If anyone is eager for this API to be finalized then please comment and let me know how it's working for you. Otherwise, I will plan to finalize later in 2022.
This would be very nice to have. We are using Github and especially larger PRs are hard to manage, if there are many comments (in Github as well as in VSCode)
So is there currently a way to filter resolved/unresolved comments in the sidebar? If not what can I modify currently to provide a visual distinction between resolved/unresolved?
there's a color difference on the icon, but that's currently it. This is the feature request you're looking for


Question: keybinding: { primary: KeyMod.Alt | KeyCode.KeyR, mac: { primary: KeyMod.CtrlCmd | KeyMod.Alt | KeyCode.KeyR }, <del> when: ContextKeyExpr.or(TerminalContextKeys.focusInAny, TerminalContextKeys.findFocus), </del> <ins> when: TerminalContextKeys.findVisible, </ins> weight: KeybindingWeight.WorkbenchContrib }, precondition: ContextKeyExpr.or(TerminalContextKeys.processSupported, TerminalContextKeys.terminalHasBeenCreated),

Type: <bBug</bAlt+C or Alt+W or Alt+R Now if area with code is in focus, broken search parameter selector will appear without search panel itself. If terminal is in focus, search panel will appear. I think it is completely unneccesary to intercept alt+c globally when no search panel is opened. In my setup it leads to conflict with alt+c fzf's key binding in terminal. VS Code version: Code 1.86.2 (, 2024-02-13T19:41:37.860Z) OS version: Linux x64 6.7.6-arch1-1 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (19)</summaryExtensionVersion ------ vscode-nginx-conf0.3.2 vscode-cython0.3.10 vscode-docker1.29.0 autopep82023.8.0 debugpy2024.2.0 isort2023.10.1 python2024.2.1 vscode-pylance2024.2.2 jupyter2024.1.1 jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.348.0 cmake-tools1.17.17 cpptools1.19.4 cpptools-extension-pack1.3.0 rust-analyzer0.3.1860 cmake0.0.17 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.87.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
This is feature - it influences bahavior of Add Selection To Next Find Match (<kbdCtrl</kbd+<kbdD</kbd) and Select all occurrences of current selection (<kbdCtrl</kbd+<kbdShift</kbd+<kbdL</kbd). However not sure how regexp is useful here, except it would be applied for next find.
Can you share a screen recording? I'm not sure if I understand what you're talking about.


Question: keybinding: { primary: KeyMod.Alt | KeyCode.KeyR, mac: { primary: KeyMod.CtrlCmd | KeyMod.Alt | KeyCode.KeyR }, <del> when: ContextKeyExpr.or(TerminalContextKeys.focusInAny, TerminalContextKeys.findFocus), </del> <ins> when: TerminalContextKeys.findVisible, </ins> weight: KeybindingWeight.WorkbenchContrib }, precondition: ContextKeyExpr.or(TerminalContextKeys.processSupported, TerminalContextKeys.terminalHasBeenCreated),

This video shows the behavior of vscode after pressing alt+c
This video shows what I expected after pressing alt+c in terminal It is configured with following lines in .zshrc:
I can repro when the widget is visible even if my focus is in the editor
Never mind, the little toolbar in the editor is coming from the editor command , not our terminal one.


Question: } @command('git.clone') <del> async clone(url?: string, parentPath?: string): Promise<void> { await this.cloneRepository(url, parentPath); </del> <ins> async clone(url?: string, parentPath?: string, options?: { ref?: string }): Promise<void> { await this.cloneRepository(url, parentPath, options); </ins> } @command('git.cloneRecursive')

<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --vscode- a directory to clone your repo into cloned repo :bug: branch context is not preserved This impacts Continue Working On--branch context is preserved for Clone in Container and Create New Codespace. I propose adding a new optional query parameter to the uri handler here: and passing that to the command as an optional argument here Then after cloning here: and before opening the repo in a new window, we would perform the ref checkout:
will you create a test plan item/verification steps for this feature?
yes I will!


Question: ) { } } <del> class CodeLensCache implements ICodeLensCache { </del> <ins> export class CodeLensCache implements ICodeLensCache { </ins> _serviceBrand: any;

<!-- 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: master Ran into this issue while preparing Monaco release in vscode repo open monaco-editor test page switch monaco-editor-core source to not found error in Dev Console is registered through which is only read by workbench We can add the singleton services to standalone but a simple standalone service can also fix the problem <img width="576" alt="image" src="https://user-" let me know if you have time for a quick fix, if not I can push my change to branch first to unblock publishing.
FYI is also made to ensure work at this moment. Unluckily our intermediate typescript files for tree shaking don't apply to yet. The commit will be cherry-picked to master later.
There is no need for , the default implementation is good enough and just needs to be brought into the editor land.
please review
can you clarify the steps for this? I'm not sure where the monaco-editor test page is
I can take this one


Question: break; } <del> const itemKindFilter = SuggestModel._createItemKindFilter(this._editor); </del> <ins> const { itemKind: itemKindFilter, showDeprecated } = SuggestModel._createSuggestFilter(this._editor); </ins> const wordDistance = WordDistance.create(this._editorWorkerService, this._editor); const completions = provideSuggestionItems( model, this._editor.getPosition(), <del> new CompletionOptions(snippetSortOrder, itemKindFilter, onlyFrom), </del> <ins> new CompletionOptions(snippetSortOrder, itemKindFilter, onlyFrom, showDeprecated), </ins> suggestCtx, this._requestToken.token );

I'd like a setting to optionally prevent deprecated things from showing up in intellisense suggestions. For example, I'd like a way to prevent from being suggested here, so that I don't use it despite a non-deprecated version being available. ! My linter can catch it, but it'd be even nicer never to see the deprecated option. There are several documentation systems that use the tag: JSDoc: TSDoc: JavaDoc: Yard (for Ruby): Other systems use different, similar tags. I'm not sure if this is an issue for the VSCode core, or for something language-specific.
Sorry if this is a duplicate or is already possible. There are enough issues here and questions/answers on Stack Overflow that it's hard to be confident. This issue is related:
Not showing deprecated suggestions can be implemented by individual language extensions today (not striking out but tracks that). Adding just to see this is something we want better VS Code api support for in some way Otherwise, we can track this as a feature request for js/s
I'd say this is a dupe of and it would be us adding some API flag and then allows users to configure how the suggest UX is handling that flag
/duplicate of
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues . See also our guidelines. Happy Coding!
Okay, that makes sense. What does "js/s" mean?
is it possible to add a setting like , so I can disable it to prevent deprecated from showing up in suggestions list?
Hey any update on that?
Verify that the setting exists and that it filters deprecated elements from IntelliSense


Question: const pendingCommentText = (this._pendingNewCommentCache[uniqueOwner] && this._pendingNewCommentCache[uniqueOwner][thread.threadId]) ?? continueOnCommentText; const pendingEdits = this._pendingEditsCache[uniqueOwner] && this._pendingEditsCache[uniqueOwner][thread.threadId]; <del> const isThreadTemplateOrEmpty = (thread.isTemplate || (!thread.comments || (thread.comments.length === 0))); const shouldReveal = thread.canReply && isThreadTemplateOrEmpty && (!thread.editorId || (thread.editorId === editorId)); </del> <ins> const shouldReveal = thread.canReply && thread.isTemplate && (!thread.comments || (thread.comments.length === 0)) && (!thread.editorId || (thread.editorId === editorId)); </ins> await this.displayCommentThread(uniqueOwner, thread, shouldReveal, pendingCommentText, pendingEdits); this._commentInfos.filter(info => info.uniqueOwner === uniqueOwner)[0].threads.push(thread); this.tryUpdateReservedSpace();

!
Caused by I caused when I fixed an issue when there are multiple text editors open with the same uri with comments. When I tried to fix I made it so when extensions call and pass in for the comments, we always expand the reply editor, resulting in the bad behavior above. I took a quick look, and it seems very common for extensions to pass in for the comments and then immediately set them.
To verify: Check out PR with comments that you left Reload to make sure there's not state left over from when you left the comments Open the file with the comments and click on the comment icon in the comment bar to expand a comment that you left Verify that the reply input button is collapsed and isn't a big empty rectangle.
Works great -verified.
<!-- UNABLETOLOCATECOMMITMESSAGE repo --Issue marked as unreleased but unable to locate closing commit in repo history. If this was closed in a separate repo you can add the label directly, or comment .
<!-- UNABLETOLOCATECOMMITMESSAGE --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased


Question: import { SettingsEditor2 } from 'vs/workbench/parts/preferences/browser/settingsEditor2'; import { DefaultPreferencesEditorInput, PreferencesEditorInput, KeybindingsEditorInput, SettingsEditor2Input } from 'vs/workbench/services/preferences/common/preferencesEditorInput'; import { KeybindingsEditor } from 'vs/workbench/parts/preferences/browser/keybindingsEditor'; <del> import { OpenRawDefaultSettingsAction, OpenSettingsAction, OpenGlobalSettingsAction, OpenGlobalKeybindingsFileAction, OpenWorkspaceSettingsAction, OpenFolderSettingsAction, ConfigureLanguageBasedSettingsAction, OPEN_FOLDER_SETTINGS_COMMAND, OpenGlobalKeybindingsAction, OpenSettings2Action } from 'vs/workbench/parts/preferences/browser/preferencesActions'; </del> <ins> import { OpenRawDefaultSettingsAction, OpenSettingsAction, OpenGlobalSettingsAction, OpenGlobalKeybindingsFileAction, OpenWorkspaceSettingsAction, OpenFolderSettingsAction, ConfigureLanguageBasedSettingsAction, OPEN_FOLDER_SETTINGS_COMMAND, OpenGlobalKeybindingsAction, OpenSettings2Action, OpenRawUserSettingsAction } from 'vs/workbench/parts/preferences/browser/preferencesActions'; </ins> import { IKeybindingsEditor, IPreferencesSearchService, CONTEXT_KEYBINDING_FOCUS, CONTEXT_KEYBINDINGS_EDITOR, CONTEXT_KEYBINDINGS_SEARCH_FOCUS, KEYBINDINGS_EDITOR_COMMAND_DEFINE, KEYBINDINGS_EDITOR_COMMAND_REMOVE, KEYBINDINGS_EDITOR_COMMAND_SEARCH, KEYBINDINGS_EDITOR_COMMAND_COPY, KEYBINDINGS_EDITOR_COMMAND_RESET, KEYBINDINGS_EDITOR_COMMAND_COPY_COMMAND, KEYBINDINGS_EDITOR_COMMAND_SHOW_SIMILAR, KEYBINDINGS_EDITOR_COMMAND_FOCUS_KEYBINDINGS, KEYBINDINGS_EDITOR_COMMAND_CLEAR_SEARCH_RESULTS

We have a setting to disable the settings split view, but it might be useful to have a command to open the user outside of the split view for a one-off. From
I am reverting the PR, it actually doesn't work. We intercept the editor open here:
Damn, it's already a part of my workflow . What's wrong with it?
So it opens the raw outside of the split view for you? For me, it actually just acts the same as the normal open settings command and opens the settings split view.
And you don't have ?
I don't have . The command itself works for me. Does it break some other functionality? ! OS version: Windows_NT x64 10.0.
I see now. Opens a split view on linux VM. Was it ever working before on non-Windows environments?
Yeah it only works on Windows, because the == check with fspath can fail due to drive letters being different. I guess that's a separate bug... I'll revert this tomorrow.
We got a good bug out of this:
Now that the settings UI exists, I don't plan on investigating much more on the JSON editor. The split JSON UI will probably go away at some point (the JSON files themselves will always remain)
BUT I CAN'T OPEN SETTINGS FILE (WITHOUT SPLIT) NOW AT ALL BECAUSE IT'S NOT LETTING ME. Are you planning to allow users to see plain json file or to forbid it completely?
We will always allow users to see the json file. Hopefully you can still open the raw json file with .
I know about that option, it's not great.
I'll close this just because I am cleaning up issues that are specific to the JSON split editor. But to be clear, editing the JSON file will never go away :)


Question: "editor.background": "#1f1f1f", "editor.findMatchBackground": "#9e6a03", "editor.foreground": "#ffffffd3", <del> "editorCursor.foreground": "#0078d4", </del> "editorGroup.border": "#ffffff17", "editorGroupHeader.tabsBackground": "#181818", "editorGroupHeader.tabsBorder": "#ffffff15",

<!-- 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.75.0-insider OS Version: Linux Hello, IMHO, the block cursor could use a different background. Default Dark+ Experimental (v2): ! ! Default Dark+: ! ! Default Dark+ Experimental (v2): with some cursor background color. For ex: ! ! ! ! Edit (one more option) (with color set to 's value, giving inverted cursor effect) ! ! Thanks


Question: return false; } <del> let rootPath = root.fsPath + (root.fsPath.endsWith(sep) ? '' : sep); let resourceFsPath = resource.fsPath; </del> <ins> let resourceFsPath = normalize(resource.fsPath); let rootPath = normalize(root.fsPath + (root.fsPath.endsWith(sep) ? '' : sep)); </ins> if (isUNC(root.fsPath) && isUNC(resource.fsPath)) { rootPath = rootPath.toLowerCase();

An information disclosure vulnerability exists in VS Code 1.71 and earlier versions. If an attacker is able to run arbitrary scripts inside of a webview (either created by extension or by core VS Code), the attacker could bypass the local resource roots check to read arbitrary files on the user's system The fix is available starting with VS Code 1.71.1. The mitigates this attack by performing input validation on the URL pointing to the repository to be cloned. Only use webviews from extensions that follow proper security measures to block script injection Do not disable VS Code's default security measures in the built-in markdown preview The patch for this can be found at An advisory for this can be found at MSRC details for this can be found at
Hi, just curious about this: The description of the vulnerability ends mid-sentence. I see the same phrasing on the GHSA advisory as well: Can it be revised to be clearer what is the nature of the vulnerability? (And of course: Thanks for finding and fixing it, and for making these advisories! Transparency and security are appreciated!)
Updated
Should the references to 1.71 in fact be 1.72?


Question: // Ask for confirmation const { confirmed } = await dialogService.confirm({ <del> message: localize('confirmClearMessage', "Do you want to clear the history of recently used commands?"), </del> <ins> message: localize('confirmClearMessage', "Do you want to clear the previous session command history?"), </ins> detail: localize('confirmClearDetail', "This action is irreversible!"), primaryButton: localize({ key: 'clearButtonLabel', comment: ['&& denotes a mnemonic'] }, "&&Clear"), type: 'warning'

Testing Linux some commands in your terminal 1 Terminal Clear Command History 1 Terminal run recent commands the commands are still there, nothing got cleared !
This is by design as clearing history only clears the previous session commands. We don't discard the current session as they're all in the active terminal marked by decorations. It does however clear the active terminal's current session history from the previous session history (which hides by default as they would duplicate the content).
I find this very counterintuitive... As no other clear command in VS Code behaves that way.
I cleared recently opened and the active windows still show up, this is essentially the same thing the terminal history is doing: !
On macOS, i run , and when i run again, i can see all the commands, including those from the previous session. <img width="802" alt="Screen Shot 2022-02-24 at 11 07 24 AM" src="https://user-"
I agree that it's a little confusing. Perhaps we should say instead?
I now get the clear command history and a clear previous session command history command. Neither command seems to be clearing the command history. I'm on Windows with pwsh. !
the change you made was to the quickaccess code, this is nothing to do with the terminal so we need to revert that
can you help with verification steps for this one. Since I do not see the "Clear Command History" in quick pick. Does this only appear on Linux?
the title of the command is
thanks. After running that commend I still see the recent commands. So the command history is not cleared. Is this expected?
I still see previous session history commands given to the terminal after running the command.
is the group called or is it or something similar? Only the first is expected to be cleared. This worked fine for me just now.


Question: switchSides = localize('switchSidesNoKb', "Run the command Diff Editor: Switch Side, which is currently not triggerable via keybinding, to toggle between the original and modified editors."); } <ins> const diffEditorActiveAnnouncement = localize('msg5', "The setting, accessibility.verbosity.diffEditorActive, controls if a diff editor announcement is made when it becomes the active editor."); </ins> const keys = ['accessibility.signals.diffLineDeleted', 'accessibility.signals.diffLineInserted', 'accessibility.signals.diffLineModified']; const content = [ localize('msg1', "You are in a diff editor."), localize('msg2', "View the next ({0}) or previous ({1}) diff in diff review mode, which is optimized for screen readers.", next, previous), switchSides, <ins> diffEditorActiveAnnouncement, </ins> localize('msg4', "To control which accessibility signals should be played, the following settings can be configured: {0}.", keys.join(', ')), ]; const commentCommandInfo = getCommentCommandInfo(keybindingService, contextKeyService, codeEditor);

has said that when switching between editors, it's unclear to him when a diff editor has been entered, though this is clear for sighted users. We should something like to fix this. cc
I think we announce whenever an editor gets focus. Each editor has a title that is announced. So I am not sure what is missing here? I would not like that we just add a new alert. Is the title of the diff editor not descriptive enough? Or is nothing getting announced (which would be a bug)
Good point, the file name is announced and says (Working Tree). is that sufficient to indicate this?
Closing for now, but will reopen based on your feedback
Just discussed with JooYoung and the redundant info is escaped/ignored by screen reader users, so we need to alert with this info
Should we consider a better announcement on focus of the text editor? how does this interact with the existing announcement?
Venkatesh observed that the editor title isn't being read at all, only the accessibility help hint, need to investigate that. EDIT: I explored and this works as expected.
Edit: we use already. This is working as expected. When a new file is opened, the title is read. When a user focuses the document, they hear the hint, if any, along with the "edit text, ...content". If that hint is disabled, they hear "edit text,...content"
which command do you use to switch between editor tabs? Is it ? I believe this issue is about when using that command, indicating if the focused editor is a diff editor via an .
What should I be looking for when verifying this?
Have some editor groups open, including ones with diff editors. Run the command . When a diff editor group is focused, you should hear "diff editor" announced by a screen reader. Disable that setting, and ensure you don't hear that. You should also hear it when navigating the open editors view. !
Using the Open Editors view, I don't see anything read about diff editors when I hit on a diff editor: !
Actually, I do see it when I toggle accessibility mode on


Question: }; const spanElement = (this.message.formatContent <del> ? renderFormattedText(this.message.content, renderOptions) : renderText(this.message.content, renderOptions)); </del> <ins> ? renderFormattedText(this.message.content!, renderOptions) : renderText(this.message.content!, renderOptions)); </ins> spanElement.classList.add(this.classForType(this.message.type)); const styles = this.stylesForType(this.message.type);

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.


Question: }; const spanElement = (this.message.formatContent <del> ? renderFormattedText(this.message.content, renderOptions) : renderText(this.message.content, renderOptions)); </del> <ins> ? renderFormattedText(this.message.content!, renderOptions) : renderText(this.message.content!, renderOptions)); </ins> spanElement.classList.add(this.classForType(this.message.type)); const styles = this.stylesForType(this.message.type);

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. !


Question: { "name": "code-oss-dev", "version": "1.94.0", <del> "distro": "0e2e9472d115a44f86c2cc3ea26fcea692643ec3", </del> <ins> "distro": "a27dc893952c71fcdc7dc52f9ea3fe51add4fe83", </ins> "author": { "name": "Microsoft Corporation" },

Testing Version: 1.90.0-insider Commit: Date: 2024-05-29T05:51:07.154Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Linux x64 5.15.0-107-generic open a file in an editor run . This opens a file selection dialog initialized to the home folder
Same problem with open folder dialog
VS Code is awesome, but the open file dialog on Linux has been ridiculously buggy for years. More than two years to fix the problem of the dialog opening in the background. The fix, in the latest version, involves using a dialog inside a portal with no type-ahead support that opens in $HOME or recent files. The open/save file dialog is a crucial control in any application. There should be a way to use the native OS dialog. I'm going to downgrade to the previous version (1.89.1) and keep it as long as it takes.
cc
We hadn't patched the portal code to support most of the file dialogs options, it is being addressed via
This is now addressed in the runtime via , fix will be available once we adopt
Reopening since we have reverted the updated due to other regressions , will be revisited in August.
This issue is not resolved for me, here is for comparison how the file dialog opens in an older version of VS Code vs. now: Good behaviour: ! Bad behaviour: !
Filed
I'm on xfce on xubuntu 22.04. Version 1.89.1-1715060508_amd64 does not have the issue. Later versions do have it. The problem is that instead of forcing the "Open File" path, to that of the current file being edited, vscode delegates the path selection to the operating system, which resolves the "Recent Files" path. Since recent files is truly not useful in vscode, I can at least pilot the path to be that of the home folder with $gsettings set startup-mode 'cwd' from the previous value. Clearly this is very inconvenient. Is there any update about it?
The issue is not resolved for me either.


Question: { "name": "code-oss-dev", "version": "1.94.0", <del> "distro": "0e2e9472d115a44f86c2cc3ea26fcea692643ec3", </del> <ins> "distro": "a27dc893952c71fcdc7dc52f9ea3fe51add4fe83", </ins> "author": { "name": "Microsoft Corporation" },

The file-open and directory-open dialogs still do not appear even though built on Electron 30.1.2. This is reproducible 100% of the time in openSUSE Tumbleweed and in Leap.
The file-open/directory-open or save dialog not being shown remains unresolved on Linux in release 1.93.1 built with electron 30.4.0.


Question: return editor.getContribution<EditorDictation>(EditorDictation.ID); } <del> private readonly widget = this._register(new DictationWidget(this.editor)); </del> <ins> private readonly widget = this._register(new DictationWidget(this.editor, this.keybindingService)); </ins> private readonly editorDictationInProgress = EDITOR_DICTATION_IN_PROGRESS.bindTo(this.contextKeyService); private sessionDisposables = this._register(new MutableDisposable());

Testing My first reaction for how to stop dictation in the editor was to click the flashing microphone. It would be cool if something happened when the flashing microphone is clicked.
I will turn this into a real with action and hover.


Question: const toRender = this._render(visibleStartLineNumber, visibleEndLineNumber, decorationsToRender, this._glyphMarginDecorationLaneCount); const lineHeight = this._lineHeight.toString(); <del> const width = this._glyphMarginWidth.toString(); </del> <ins> const width = (Math.round(this._glyphMarginWidth / this._glyphMarginDecorationLaneCount)).toString(); </ins> const common = '" style="width:' + width + 'px' + ';height:' + lineHeight + 'px;'; const output: string[] = [];

Presumably related to . Adding breakpoints to lines with gutter icons causes the icon to be stretched and cropped: ! I don't know if related, but I'm using :
The problem is that we set each decoration 's width to be the width of the entire gutter (which is sized to fit potentially multiple decorations, so sets which ends up stretching the decoration to fit the entire gutter instead of just its lane.
Fix looks good, thanks! /verified


Question: import { Selection } from 'vs/editor/common/core/selection'; import { SingleTextEdit, TextEdit } from 'vs/editor/common/core/textEdit'; import { TextLength } from 'vs/editor/common/core/textLength'; <ins> import { ScrollType } from 'vs/editor/common/editorCommon'; </ins> import { Command, InlineCompletionContext, InlineCompletionTriggerKind, PartialAcceptTriggerKind } from 'vs/editor/common/languages'; import { ILanguageConfigurationService } from 'vs/editor/common/languages/languageConfigurationRegistry'; import { EndOfLinePreference, ITextModel } from 'vs/editor/common/model';

type at the end of line have ghost text accept it word by word when reaching the end of the viewport accepted words aren't revealed https://user-
fyi that I have pushed as a fix for this
Thank you! Sorry for not fixing this, I thought the fix was more complicated.
Accepting single word seems to move the horizontal scroll, but tabbing to accept the whole line does not scroll. Is that expected?
Marking as verified as word by word works.


Question: return this._commentThread; } <ins> public get expanded(): boolean | undefined { return this._isExpanded; } </ins> private _commentOptions: languages.CommentOptions | undefined; constructor(

VSCode Version: 1.36.0 OS Version: Windows 10 Repro steps: Live Share extension 1.0.488, start a collaboration session two comment threads on a single line. Comment on a line, 3 for example Comment on a second line, 4 for example Delete line 3 Now there are two comment threads on line 3 (the line that moved up from 4) /Collapse the comments with the marker Collapsing/opening such comments might need a rework. Currently I can collapse each individually, and if all are collapsed (or all open), the box on the gray line opens (or closes) all threads. However, if only some of the threads are collapsed, the gray box toggles between the set of open threads and the threads which were collapsed. It never collapses all threads to return to code, and requires each remaining thread to be collapsed individually. Originally reported in Live Share issue
As I was just about to file the same thing, here is the screencast I created for illustration: !
I agree the current behavior is a bit confusing. Clicking in the gutter is a common way to collapse open comments. However, the workflow fails when multiple comments are on the same line. This forces the user to think and use the alternative workflow (top-right icon). Suggested behavior: if at least one comment is expanded, collapse all comments on the line otherwise, expand all the comments The condition could also be reversed (expand if the line has both expanded and collapsed comments).
Since we just came across the relevant code again in another context: clicks on the gutter icon currently toggle the collapsible states for all threads on that line independently here: already exists as a private property, if there was a public getter for it, behavior like the one suggested by above could probably be implemented very locally in the location I linked to above. let us know if that sounds reasonable and we can make a PR.
yes, this sounds reasonable to me. l would accept a PR!
I opened .


Question: getDefaultShell(options: IShellLaunchConfigResolveOptions): Promise<string>; getDefaultShellArgs(options: IShellLaunchConfigResolveOptions): Promise<string | string[]>; getEnvironment(remoteAuthority: string | undefined): Promise<IProcessEnvironment>; <del> createProfileFromShellAndShellArgs(shell?: unknown, shellArgs?: unknown): Promise<ITerminalProfile | undefined>; </del> <ins> createProfileFromShellAndShellArgs(shell?: unknown, shellArgs?: unknown): Promise<ITerminalProfile | string>; </ins> } export interface IShellLaunchConfigResolveOptions {

Testing With the following settings: I saw the terminal migration notification and then clicked "Migrate", and my settings changed to: Which is defintely not what I expected to happen.
Perhaps if the shell/shellArgs match one of the detected profiles, the name of that profile can be used? So in the sample above,
I'm also kinda confused by this... here's what I had: and it turned it into:
The behavior should be: If there is an exact match (eg. just ), it should assign the existing profile as the default (). If there is not an exact match (eg. ), it should add the profile to the list and set it as the default. As for the name maybe something like would be best.
To verify, see and try other combinations
or could you pls verify this?
with the following: I don't get a notification. Is that expected?
If you've already said don't show again to the notification in that workspace, yes.
ah... I hit the which didn't show the notification until I reloaded the window.
that was another fix that went in to make sure we're not annoying
Migration doesn't seem to be working for me. Here's a gif: ! These are the same settings as here
Ah looks like if I already define then this migration doesn't work. If I delete that setting (and use instead as the default profile, the migration works.
Meaning if you set the to the name of a profile that already exists within your it doesn't work? I think that's by design.
Gotcha. The only thing I'll mention is this, with a defined does not prompt me: but this without it defined does prompt me:
I guess I would expect the migration to still happen (and a new profile be to my existing ) but maybe that's out of scope.
That seems wrong. It should happen as long as you haven't said don't show again. I'll try it.
ah... just opened dev tools:
it's working for me on Windows.
Hmm what does that mean?
Here's a repro on non-Windows without PowerShell:
any errors in dev tools with that repro? can you turn on trace logging? and search for 'migrat'
Beyond this: I don't see anything... which Output should I dig into specifically?
Run set log level -trace -open developer tools.


Question: getDefaultShell(options: IShellLaunchConfigResolveOptions): Promise<string>; getDefaultShellArgs(options: IShellLaunchConfigResolveOptions): Promise<string | string[]>; getEnvironment(remoteAuthority: string | undefined): Promise<IProcessEnvironment>; <del> createProfileFromShellAndShellArgs(shell?: unknown, shellArgs?: unknown): Promise<ITerminalProfile | undefined>; </del> <ins> createProfileFromShellAndShellArgs(shell?: unknown, shellArgs?: unknown): Promise<ITerminalProfile | string>; </ins> } export interface IShellLaunchConfigResolveOptions {

you should see a migration message. migrated from shell/shellArgs...
I wonder if this could be the issue
Hmmm I don't see
The fix here is probably:
Even better is marking the type as readonly too:
We might be able to catch this in the future with
I don't understand what's going wrong here though - if userValue is undefined, profiles get set to already
I'd think making it readonly would be even worse since then we can't add properties to it - such as the newly created profile
Which works fine, the failure case was when had profiles set. The there just corrects the type we're receiving from the config service
ok, should this be a candidate or moved to June?
I think it meets the candidate bar, we really want migration to be solid


Question: this._matchesCount.className = 'matchesCount'; } this._matchesCount.innerText = ''; <del> const label = count === undefined || count.resultCount === 0 ? `No Results` : `${count.resultIndex + 1} of ${count.resultCount}`; </del> <ins> let label; if (count?.resultCount === -1) { label = ''; } else { label = count === undefined || count.resultCount === 0 ? NLS_NO_RESULTS : strings.format(NLS_MATCHES_LOCATION, count.resultIndex + 1, count?.resultCount); } </ins> this._matchesCount.appendChild(document.createTextNode(label)); this._matchesCount.classList.toggle('no-results', !count || count.resultCount === 0); this._findInput?.domNode.insertAdjacentElement('afterend', this._matchesCount);

<!-- 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 VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -


Question: getSelection(): (MarkerTableItem | null)[] { const selection = this.table.getSelection(); <del> return selection.length > 0 ? [this.table.row(selection[0])] : []; </del> <ins> return selection.length > 0 ? [...selection.map(i => this.table.row(i))] : []; </ins> } getVisibleItemCount(): number {

Testing Not sure if this lack of functionality blocks anything truly useful, but at least in the treeview, you can multi-select problems and copy them to the clipboard. In the table view you can't.
This also has the side effect of losing a multi-select that you may have had in the treeview.
what was the thinking for enabling multi-select in the problems treeview? Was there a particular scenario or this is what the default behaviour is for a treeview? If there is a real scenario, than we should enable multi-select in the table as well.
You can copy multiple problems is the primary use case.
that makes sense. Thanks!


Question: "@typescript-eslint/eslint-plugin": "^5.57.0", "@typescript-eslint/experimental-utils": "^5.57.0", "@typescript-eslint/parser": "^5.57.0", <del> "@vscode/gulp-electron": "^1.35.0", </del> <ins> "@vscode/gulp-electron": "^1.36.0", </ins> "@vscode/l10n-dev": "0.0.21", "@vscode/telemetry-extractor": "^1.9.9", "@vscode/test-web": "^0.0.41",

Today when running out of sources and/or building, we get some components from online resources such as GitHub or our Marketplace. We should add SHA256 checksum verification to these: [x] [x] built-in extensions [x] electron
Adding the foundation for this for and extensions in


Question: getFocus(): (MarkerTableItem | null)[] { const focus = this.table.getFocus(); <del> return focus.length > 0 ? [this.table.row(focus[0])] : []; </del> <ins> return focus.length > 0 ? [...focus.map(f => this.table.row(f))] : []; </ins> } getHTMLElement(): HTMLElement {


Question: async resetLocal(): Promise<void> { this.checkEnablement(); this.storageService.remove(LAST_SYNC_TIME_KEY, StorageScope.APPLICATION); <del> if (this.activeProfileSynchronizers) { for (const [synchronizer] of this.activeProfileSynchronizers.values()) { try { await synchronizer.resetLocal(); } catch (e) { this.logService.error(e); } </del> <ins> for (const [synchronizer] of this.activeProfileSynchronizers.values()) { try { await synchronizer.resetLocal(); } catch (e) { this.logService.error(e); </ins> } <del> this.clearActiveProfileSynchronizers(); </del> } <ins> this.clearActiveProfileSynchronizers(); </ins> this._onDidResetLocal.fire(); this.logService.info('Did reset the local sync state.'); }

Error while turning off settings sync ! Might happen when turning off settings sync while a sync is happening
Can't repro this anymore.


Question: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.4.0", <del> "electron": "19.0.11", </del> <ins> "electron": "19.0.12", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

Found this stack while scanning through some failing smoke test runs From Deepak:
What are some verification steps for this issue?
I did check logs last week and could no longer find this.


Question: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.4.0", <del> "electron": "19.0.11", </del> <ins> "electron": "19.0.12", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?


Question: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.4.0", <del> "electron": "19.0.11", </del> <ins> "electron": "19.0.12", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

Type: <bBug</bIn the most recent insiders version, audio cues no longer play. I ensured that the audio cues I expect are enabled (e.g. error) and entered the following json as an example: I ensured that the error was reported when moving through errors with f8, yet the cue doesn't play when I come across the line with up/down arrow keys VS Code version: Code - Insiders 1.71.0-insider (, 2022-08-05T07:36:58.753Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No <!-- generated by issue reporter --
cc
We didn't touch anything there the last months, maybe it is caused by an electron update. Will investigate for the next release.
I can reproduce this. Easy repros steps: 1 list audio cues command cues do not produce sound Works fine on latest stable. Does not work on Insiders. fyi since most likely caused by Electron update (thus adding label). Maybe our future planned ffmpeg change will fix this? thanks a lot for reporting this, and sorry about this breakage.
You're welcome, I'm running insiders for a reason Looking forward to a fix.
Let me also assign since we will now support would you like that all our audio cues are in format? If yes, would you like me to reach out to our sound designer for this? Thanks
can you track the conversion in a separate issue, this particular issue is a regression with the ffmpeg build shipped with internal builds. There was a recent build architecture change and it impacted this. I would like to close this issue as part of the next Electron version update :)
makes sense, thanks! There is actually already this one which we can use for the conversion
The same problem using code-insiders into a fedora workstation 36.
It is working again with orca.
lovely, thanks for confirming. Adding verified label.
For me it also works like a charm on Windows.
For some reason I can't explain, this issue seems to have returned on my fedora workstation. No sound is played when I move the cursor to lines that contain breakpoints, errors and etc. Version: 1.71.0-insider Commit:
Confirmed on Windows. Could tests for this be somehow?


Question: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.4.0", <del> "electron": "19.0.11", </del> <ins> "electron": "19.0.12", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

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


Question: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.4.0", <del> "electron": "19.0.11", </del> <ins> "electron": "19.0.12", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

<!-- 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.


Question: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.4.0", <del> "electron": "19.0.11", </del> <ins> "electron": "19.0.12", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

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 .


Question: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.4.0", <del> "electron": "19.0.11", </del> <ins> "electron": "19.0.12", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

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!


Question: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.4.0", <del> "electron": "19.0.11", </del> <ins> "electron": "19.0.12", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

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


Question: if (temp) { return this.userDataProfilesService.createNamedProfile(`${profileName} ${this.getProfileNameIndex(profileName)}`, { ...options, transient: temp }); } <del> enum ImportProfileChoice { Overwrite = 0, CreateNew = 1, Cancel = 2 } const { result } = await this.dialogService.prompt<ImportProfileChoice>({ </del> <ins> const { confirmed } = await this.dialogService.confirm({ </ins> type: Severity.Info, <del> message: localize('profile already exists', "Profile with name '{0}' already exists. Do you want to overwrite it?", profileName), buttons: [ { label: localize({ key: 'overwrite', comment: ['&& denotes a mnemonic'] }, "&&Overwrite"), run: () => ImportProfileChoice.Overwrite }, { label: localize({ key: 'create new', comment: ['&& denotes a mnemonic'] }, "&&Create New Profile"), run: () => ImportProfileChoice.CreateNew }, ], cancelButton: { run: () => ImportProfileChoice.Cancel } }); if (result === ImportProfileChoice.Overwrite) { return profile; } if (result === ImportProfileChoice.Cancel) { return undefined; } // Create new profile const name = await this.quickInputService.input({ placeHolder: localize('name', "Profile name"), title: localize('create new title', "Create New Profile"), value: `${profileName} ${this.getProfileNameIndex(profileName)}`, validateInput: async (value: string) => { if (this.userDataProfilesService.profiles.some(p => p.name === value)) { return localize('profileExists', "Profile with name {0} already exists.", value); } return undefined; } </del> <ins> message: localize('profile already exists', "Profile with name '{0}' already exists. Do you want to replace its contents?", profileName), primaryButton: localize({ key: 'overwrite', comment: ['&& denotes a mnemonic'] }, "&&Replace") </ins> }); <del> if (!name) { </del> <ins> if (!confirmed) { </ins> return undefined; } <del> return this.userDataProfilesService.createNamedProfile(name); </del> <ins> return profile.isDefault ? profile : this.userDataProfilesService.updateProfile(profile, options); </ins> } else { return this.userDataProfilesService.createNamedProfile(profileName, { ...options, transient: temp }); }

<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --when you import a profile file, vscode will create a new profile but not overwrite current one or merge it to current one Actually I don't need so many profiles, the default profile is enough for me. sometimes I just want to import a keybinding settings from some one, and keep my other settings after I import it, WHAT HAPPEND!!!, all my other settings and extension are gone!!! This is unreasonable! what vscode should do is merging(or overwriting) new keybinding to my old one!! <!-- Describe the feature you'd like. --
Can I have a try on this? I'm new to contributing to this repo but want to try out stuff and get along with starting out at the same time..
Edit: Ignore this, I misread this with other issue
Just wondering is not this same as Can you please distinguish your ask from the other?
partially like But I request more flexibility: Suppose current profile is profile X (X can be default or user profile) when I import A profile, that will be: A.keybinding, A.UI, A.extensions ..... and I choose A.keybindings only to import what I expect: there are 2 options for user when importing: option 1 - merge to current profile, (so X profile's keybindings overwritten but other part of settings kept) option 2 - or create a new profile partially basing on what imported (this is what VSCode currently does )
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
<!-- -c9e0-7adb-d31b- --:slightlysmilingface: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our . Happy Coding!
?


Question: if (temp) { return this.userDataProfilesService.createNamedProfile(`${profileName} ${this.getProfileNameIndex(profileName)}`, { ...options, transient: temp }); } <del> enum ImportProfileChoice { Overwrite = 0, CreateNew = 1, Cancel = 2 } const { result } = await this.dialogService.prompt<ImportProfileChoice>({ </del> <ins> const { confirmed } = await this.dialogService.confirm({ </ins> type: Severity.Info, <del> message: localize('profile already exists', "Profile with name '{0}' already exists. Do you want to overwrite it?", profileName), buttons: [ { label: localize({ key: 'overwrite', comment: ['&& denotes a mnemonic'] }, "&&Overwrite"), run: () => ImportProfileChoice.Overwrite }, { label: localize({ key: 'create new', comment: ['&& denotes a mnemonic'] }, "&&Create New Profile"), run: () => ImportProfileChoice.CreateNew }, ], cancelButton: { run: () => ImportProfileChoice.Cancel } }); if (result === ImportProfileChoice.Overwrite) { return profile; } if (result === ImportProfileChoice.Cancel) { return undefined; } // Create new profile const name = await this.quickInputService.input({ placeHolder: localize('name', "Profile name"), title: localize('create new title', "Create New Profile"), value: `${profileName} ${this.getProfileNameIndex(profileName)}`, validateInput: async (value: string) => { if (this.userDataProfilesService.profiles.some(p => p.name === value)) { return localize('profileExists', "Profile with name {0} already exists.", value); } return undefined; } </del> <ins> message: localize('profile already exists', "Profile with name '{0}' already exists. Do you want to replace its contents?", profileName), primaryButton: localize({ key: 'overwrite', comment: ['&& denotes a mnemonic'] }, "&&Replace") </ins> }); <del> if (!name) { </del> <ins> if (!confirmed) { </ins> return undefined; } <del> return this.userDataProfilesService.createNamedProfile(name); </del> <ins> return profile.isDefault ? profile : this.userDataProfilesService.updateProfile(profile, options); </ins> } else { return this.userDataProfilesService.createNamedProfile(profileName, { ...options, transient: temp }); }

I would think this is not a good one to start at and recommend to look for issues labelled with or
I really want to try out.. just to experience and I think I would be able to do it. Even if it's not a good first issue I have contributed to other open source repos. Can I?
Sure, here is the starting point
Thanks a lot for this I was checking your PR with the user-profile feature implementation.. For now I'm just figuring out stuff that is already present. Just a single doubt that I had was about the merging of profiles.. would the editor be like a merge editor that opens whenever we get a merge conflict on git..? Or something else with checkboxes on which settings to get imported from each of the sides(current and imported one)? I'll try my best
For the sake of simplicity, during conflicts, I would simply override with the new one.
Also
Note to self: see for manual workaround.
You can now import and replace any existing profile (including Default profile) from new Profiles Editor UI
To verify: Create a profile A and configure with some settings and extensions Export the profile A to the disk Change some settings and extensions in the profile Import the profile A You should be able to import the profile with name A replacing the existing profile
When I export the profile, install some new extensions, then import the profile with the same name, I would expect the installed extensions to disappear from my extensions list, but that doesn't seem to be the case
It is working for me, ie., I only see the extension from the imported profile. After importing, extensions are getting replaced. Can you please share the exact steps to repro?
Using vscode 1.92.2, I can't figure out how to get to that UI. Where do I find it?
search settings for "profiles experimental"
Thank you!


Question: { link: 'foo 339', prefix: undefined, suffix: ' 339', hasRow: true, hasCol: false }, { link: 'foo 339:12', prefix: undefined, suffix: ' 339:12', hasRow: true, hasCol: true }, { link: 'foo 339.12', prefix: undefined, suffix: ' 339.12', hasRow: true, hasCol: true }, <ins> { link: 'foo 339.12-14', prefix: undefined, suffix: ' 339.12-14', hasRow: true, hasCol: true, hasRowEnd: false, hasColEnd: true }, { link: 'foo 339.12-341.14', prefix: undefined, suffix: ' 339.12-341.14', hasRow: true, hasCol: true, hasRowEnd: true, hasColEnd: true }, </ins> // Double quotes { link: '"foo",339', prefix: '"', suffix: '",339', hasRow: true, hasCol: false },

The : This doesn't currently work in VSCode. It does support a very wide range of formats and I don't recall ever seeing this format before (even from GNU tools) so I suspect nobody else uses it. Nonetheless it's easy to add support in VSCode. See
Doesn't seem to work, see <img width="825" alt="Screenshot 2023-08-29 at 14 41 05" src=""
The PR intentionally left that out: But it should be easy to add so will leave this open.


Question: // Do not trigger state if current state is manual and incoming state is automatic if (!isManualToAutoTransition) { this.setState(newState); <ins> } else { // Reset the new state after getting code actions back. setTimeout(() => { this.setState(newState); }, 500); </ins> } }, undefined); this._codeActionOracle.value.trigger({ type: CodeActionTriggerType.Auto, triggerAction: CodeActionTriggerSource.Default });

Under some circumstances, the Code Action button won't go away and will still run its assign command (incorrectly) Steps to Reproduce: an error with 'Quick Fix' available ! the cursor on the same line and press to bring up the quickfix ! to cancel ! the code action button ! the button again ! again ! ! at step 4. the button should disappear, but it does not I found this bug while adding Code Actions to my personal extension VS Code Version: 1.88.1 OS Version: Windows 11


Question: { "name": "code-oss-dev", "version": "1.88.0", <del> "distro": "37f287ed9d23ce03684ef672b6b295c13afc9fa5", </del> <ins> "distro": "340432a8308f66007779ec2133ee39e6995006cb", </ins> "author": { "name": "Microsoft Corporation" },

Perhaps we forgot to update the distro json files (for stable, insiders, oss)?
!
it was to distro weeks and many commits ago. I'm not seeing the same error, even when that API is used in insiders/pre-release. - Do you know if I forgot a step for enabling this?
I think there's a typo, in of distro you have `"NotebookCellExecution", and in jupyter extension you have , notice the casing of the first char


Question: import { IKeyboardEvent } from 'vs/base/browser/keyboardEvent'; import { KeyCode } from 'vs/base/common/keyCodes'; <del> import { Disposable, toDisposable } from 'vs/base/common/lifecycle'; </del> <ins> import { Disposable, DisposableStore, toDisposable } from 'vs/base/common/lifecycle'; </ins> import { URI } from 'vs/base/common/uri'; import { IEditorConstructionOptions } from 'vs/editor/browser/config/editorConfiguration'; import { EditorExtensionsRegistry } from 'vs/editor/browser/editorExtensions';

It doesn't matter in this case, but note that you collect all the keyListener disposables in the store of the AccessibleView class (even if you dispose them in , but the disposable is still in the disposableStore). This can lead to memory leaks. I can really recommend to compose components according to their life times. I think here the lifetime of the rendered content is owned by the caller of (the caller is supposed to call on the result). So the disposable returned by should be owned by whatever you return in . I suggest to create a DisposableStore in render, push the key listener to it once the text model resolves and return the disposable store at the end of render (also add the to the store). Also, note that the getTextModel promise can resolve after the caller called dispose. Originally posted by in


Question: background-size: 16px; } <del> @keyframes shift { 0% { transform: translateX(0px); } 33%{ transform: translateX(0.5px); } 66% { transform: translateX(-0.5px); } } .monaco-toolbar.config .monaco-action-bar .action-item { animation-duration: 1.2s; animation-iteration-count: infinite; animation-name: shift; } .monaco-toolbar.config .monaco-action-bar .action-item:nth-child(odd) { animation-delay: 0.6s; } </del> .monaco-dropdown-with-default { display: flex !important; flex-direction: row;

I recently noticed an animation to indicate toolbar actions can be changed: ! This seems to be inspired by Safari toolbar when you edit it: ! I am seeing a few issues with our approach: we allow to change visibility of actions in a lot of places (activity bar, status bar) where currently there is no such animation in Safari to get into this mode, the user explicitly picks an action "Customize Toolbar" while for us it starts on right click already in Safari you can actually grab an action and move it, I even think they only animate the action to make that more obvious (not so much the fact that you can hide the action) I would vote for not having the animation until we can support what Safari does including to drag and reorder actions. I think the menu makes it already clear what the right click gesture allows you to do: <img width="299" alt="image" src="https://user-"
Yes, thanks, this feels very strange to me. I don't think animating the whole menubar make sense when you are only operating on a single item.
How about beginning a right-click menu with an inactive entry that acts as a header? Something like "Button Visibility". It would also act as a protection against accidental hiding, since I can imagine some folk inadvertently pressing right button down, moving the mouse a few pixels right, releasing the button and seeing vanish the button they intended to actuate. Especially on Linux where there's a longstanding issue about this happening on context menus at certain Zoom levels and certain places on the screen.
related/motivation
Well, strictly speaking you operate on the whole menu because you also have toggle actions for all its entries. I like that direction. We already do something similar to right click the overflow item. You cannot hide that but you get a disabled "Hide" entry for consistency. On the flip side it is bogus use of menu items as "headers" <img width="340" alt="Screenshot 2022-09-29 at 08 23 30" src="https://user-"Overall the motivation for same kind of animation is mostly the . Left and right click show a context menu which do very different things but look very similar
Any scope for changing the button icon when in this edit mode? Maybe to pencil or gearwheel.
Note that animations like this look pretty terrible on standard DPI monitors due to the blurriness.