jiebi/CodeConvo huggingface dataset:
Change:
"vscode-proxy-agent": "^0.12.0", "vscode-regexpp": "^3.1.0", "vscode-textmate": "7.0.1", <del> "xterm": "5.1.0-beta.13", </del> <ins> "xterm": "5.1.0-beta.15", </ins> "xterm-addon-canvas": "0.3.0-beta.1", "xterm-addon-search": "0.11.0-beta.1", "xterm-addon-serialize": "0.9.0-beta.2", "xterm-addon-unicode11": "0.5.0-beta.1", "xterm-addon-webgl": "0.14.0-beta.8", <del> "xterm-headless": "5.1.0-beta.13", </del> <ins> "xterm-headless": "5.1.0-beta.15", </ins> "yauzl": "^2.9.2", "yazl": "^2.4.3" },

Discussion:
Testing with EDIT or https://user-
!
!
weird behavior on too !
also happens with
also lines aren't resizing !
did some change happen around trusted types? The dynamically loaded script needs to set inline attributes/innerHTML
No, nothing that I am aware of. Tho, the assignment () should have never worked with trusted types enabled because it's a bare string, not If you have to use assignment (which should be the exception) you need to use a trusted types policy and create trusted html through that. This is a sample: However, you should try to avoid that and keep things more simple, e.g use and/or
Ah you're right, this was a coding error introduced with underlines:
Change:
} const DEBUG_TASK_ERROR_CHOICE_KEY = 'debug.taskerrorchoice'; <ins> const ABORT_LABEL = nls.localize('abort', "Abort"); const DEBUG_ANYWAY_LABEL = nls.localize({ key: 'debugAnyway', comment: ['&& denotes a mnemonic'] }, "&&Debug Anyway"); const DEBUG_ANYWAY_LABEL_NO_MEMO = nls.localize('debugAnywayNoMemo', "Debug Anyway"); </ins> <del> export class DebugTaskRunner { </del> <ins> interface IRunnerTaskSummary extends ITaskSummary { cancelled?: boolean; } export class DebugTaskRunner implements IDisposable { </ins> <del> private canceled = false; </del> <ins> private globalCancellation = new CancellationTokenSource(); </ins> constructor( @ITaskService private readonly taskService: ITaskService,

Discussion:
Clone and npm install. Hit F5, it never starts: <img width="484" alt="image" src=""I am on macOS.
This is probably because a prelaunch task is still running / your problem matchers haven't matched anything. Please make sure you have the right problem matchers installed, otherwise I suggest opening issues for them if they don't match correctly.
Would be great if debug could give me a hint.
Will keep open to track it, it's not a rare problem
We should also keep the terminal open if the task fails, currently it closes immediately which can be confusing
Would also be nice if we could cancel the pending launch attempt, e.g. by showing the debug toolbar immediately and disabling all buttons except the stop button. Right now when I get into this state I end up just reloading the whole window and incurring the pain of all extensions reactivating, which takes several seconds on my machine (git, TS etc)
After 10 seconds we'll show !
<!-- 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
Change:
font-size: 11px; } <del> .debug-pane .monaco-list-row .expression { display: flex; } </del> .debug-pane .monaco-list-row .expression .actionbar-spacer { flex-grow: 1; }

Discussion:
The new lazy variable evaluation button line-height or dimensions appear to be too large. The button creates frequent gaps in-between node items and creates unsightly misalignment. This is not a settings font issue because the issue appeared with the change to the lazy evaluation button in version 1.67.1. This new button does not improve JavaScript debugging. The ellipsis button did not do this. Version: 1.67.1 (user setup) Commit: Date: 2022-05-06T12:37:03.389Z Electron: 17.4.1 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Windows_NT x64 10.0. Does this issue occur when all extensions are disabled?: Yes Steps to Reproduce: JavaScript object to console window the gaps between expandable nodes any collapsed variable to evaluate. The item will jump and become misaligned. !
Hey is there a reason that the variables view tree is 22px tall while the hover variables rows are 18px tall? I just noticed this.
I think the idea is to make the debugHover tree smaller, while the other trees in views should be larger. The problem here seems to be that the debugHover reuses the and by that the height of the hover items is 22. So the height should be configurable, and debugHover should be able to say to the variableDelagate that the height is 18 in this case.
The variables tree in the debug hover is correctly sized. It's just a CSS issue on that one button. I guess it's intentional, and that's fine, so I'll just fix the css.
okey. Thanks for fixing
This broke the alignment of the lazy button in the debug console because the text wraps there
Change:
private async smartCommit( repository: Repository, getCommitMessage: () => Promise<string | undefined>, <del> opts?: CommitOptions </del> <ins> opts: CommitOptions </ins> ): Promise<boolean> { const config = workspace.getConfiguration('git', Uri.file(repository.root)); let promptToSaveFilesBeforeCommit = config.get<'always' | 'staged' | 'never'>('promptToSaveFilesBeforeCommit');

Discussion:
Issue Type: <bBug</bWhen I drill down into the git menu and choose the option to , I really don't need the same confirmation dialog as when I just hit the top-level check mark in the source control pane. The dialog tells me ; this is an incorrect warning at this stage, since I clearly invoked it by choosing . I certainly don't want to choose the option in response to this warning, since it's a good warning to have when I accidentally hit the checkmark without staging any changes. VS Code version: Code 1.67.0 (, 2022-05-04T12:14:47.100Z) OS version: Darwin x64 19.6.0 Restricted Mode: No <!-- 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.68.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Change:
} }, "wordPattern": { <del> "pattern": "(-?d*.dw*)|([^`~!%^&*()-=+[{]}|;:'",.<>/?s]+)", </del> <ins> "pattern": "(-?d*.dw*)|([^`~@!%^&*()-=+[{]}|;:'",.<>/?s]+)", </ins> }, "indentationRules": { "decreaseIndentPattern": {

Discussion:
<!-- 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. --In Visual Studio, the symbol is considered a trigger character inside JSDocs, and so the appropriate completions are displayed without having to use ctrl + Space. ! It would be great if this was also offered by VS Code :)
Are trigger characters supposed to override the setting? We disable quick suggestions in comments by default
It seems like VS Code already has some smarts to know that things are a little different within a JSDoc tag's . How does that work?
We treat the parts inside of as being code again. This is done using some textmate grammar tricks (there's a special scope that tells VS Code to treat this part of the comment as code) This doesn't apply when you type though as it still looks like we're in a normal comment at that point
Yes, trigger characters are "stronger" than quick suggest and work independent of the setting. However, a trigger character that's also a word character is considered a quick suggest case (hand the setting will apply).
Quick update: If I set , then I get completions after typing inside JSDocs. This isn't great though because then I also get snippet completions (e.g. after typing a ). It would be great if JSDocs could be treated as special comments where just a subset of completions is valid (not sure if this involves changes from VS Code or TypeScript).
This is the current experience in Visual Studio BTW.
This works if I revert . Since this seems more important, I'll do that and reopen
<!-- 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
Change:
preferencesService = <IPreferencesService>{}; contextMenuService = <IContextMenuService>{}; Registry.as<IConfigurationRegistry>(Extensions.Configuration).registerConfiguration(configuration); <del> settingRenderer = new SimpleSettingRenderer(configurationService, contextMenuService, preferencesService, { publicLog2: () => { } } as any); </del> <ins> settingRenderer = new SimpleSettingRenderer(configurationService, contextMenuService, preferencesService, { publicLog2: () => { } } as any, { writeText: async () => { } } as any); </ins> }); suiteTeardown(() => {

Discussion:
Testing Click on a setting link in the release notes Get a tooltip "View '<title' in Settings" context menu It seems strange to open a context menu on left-click and to open one with only a single menu item. Can we skip doing this if "View" is the only action?
My preference would be to keep it consistent so that a context menu always opens when the button is clicked. There was some discussion of adding a "copy setting id" item in there too, which would fix the only-one-item issue.
Will be fixed by , which adds a "copy" action to the menu.
Another option is to open the context menu when the "gear" icon is hit, but go directly to the setting if the text is clicked (or vise versa)
Change:
rename(title?: string): Promise<void>; /** <del> * Triggers a quick pick to change the icon of this terminal. </del> <ins> * Sets or triggers a quick pick to change the icon of this terminal. </ins> */ <del> changeIcon(): Promise<void>; </del> <ins> changeIcon(icon?: TerminalIcon): Promise<TerminalIcon | undefined>; </ins> /** <del> * Triggers a quick pick to change the color of the associated terminal tab icon. </del> <ins> * Sets or triggers a quick pick to change the color of the associated terminal tab icon. </ins> */ <del> changeColor(): Promise<void>; </del> <ins> changeColor(color?: string): Promise<string | undefined>; </ins> /** * Triggers a quick pick that displays recent commands or cwds. Selecting one will

Discussion:
Repro: Open multiple terminals Select multiple terminal tabs Right click and change color Change color only a single terminal is changed Real context stored with the action was done recently as part of Related:
/duplicate
Tracking each action separately
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 . See also our . Happy Coding!
I'm not sure this is worth fixing as color is meant to differentiate between tabs. Same for the icon/ renaming.
you might want multiple red though, right now it doesn't work as expected. We were actually doing this wrong by querying which tabs were selected also, after we get the actual instances this was triggered on passed into the action, so we can probably remove the special tab instance command as part of this.

Repro: Open multiple terminals Select multiple terminal tabs Right click and change icon Change icon only a single terminal is changed Real context stored with the action was done recently as part of Related:
Change:
"keytar": "7.6.0", "minimist": "^1.2.5", "native-is-elevated": "0.4.3", <del> "native-keymap": "3.1.0", </del> <ins> "native-keymap": "3.2.1", </ins> "native-watchdog": "1.3.0", "node-pty": "0.11.0-beta11", "spdlog": "^0.13.0",

Discussion:
<!-- 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.64.0 OS Version: Linux (Windows might fail too, in the same or in different ways) Follow-up to Steps to Reproduce: See the repo, go to , run for 10-30 minutes
I looked at for issue details. We are facing the same issue in the project. Since the release, running our tests using fails on Windows runner (Windows version 1809) in 100% cases. Every time the mocha runs all tests, they all succeed, but the process finishes with exit code . VS Code version works well. Example CI jobs:
note that I haven't tested on Windows, and it might be a different issue. I suggest attaching a crash report. I got mine by editing our to add .
Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from:
I'm not sure how, we currently do this:
See Search for "insider"
Thanks for the logs, crash trace is same as this could only happen if the was never destroyed. Couple of next steps, please test with the insiders as suggested and confirm if the crash repros. In case crash persists, we can add some logging to confirm whether thread safe function was marked for removal We could also refactor the cleanup to rely on instead.
Is this supposed to have been fixed again in between 1.64 and the latest Insiders build? Anyway, it crashed again, after 31 minutes:
The latest insiders from today now contains a fix for the crash caused by a use after free in .

I'd appreciate it if you could validate that you're no longer seeing this crash.
Ran without crashing for 1h 17m, I think it's fixed. Thank you! /verified
For what it's worth, the issue is fixed for the project as well. Thank you
Given our green CI history, marking as verified.
Change:
template.descriptionElement.setAttribute('checkbox_label_target_id', baseId + '_setting_item'); } <ins> template.otherOverridesElement.innerHTML = ''; </ins> if (element.overriddenScopeList.length) { const otherOverridesLabel = element.isConfigured ? localize('alsoConfiguredIn', "Also modified in") : localize('configuredIn', "Modified in"); <del> template.otherOverridesElement.textContent = `(${otherOverridesLabel}: ${element.overriddenScopeList.join(', ')})`; } else { template.otherOverridesElement.textContent = ''; </del> <ins> DOM.append(template.otherOverridesElement, $('span', null, `(${otherOverridesLabel}: `)); for (let i = 0; i < element.overriddenScopeList.length; i++) { let view = DOM.append(template.otherOverridesElement, $('a.modified-scope', null, element.overriddenScopeList[i])); if (i !== element.overriddenScopeList.length - 1) { DOM.append(template.otherOverridesElement, $('span', null, ', ')); } else { DOM.append(template.otherOverridesElement, $('span', null, ')')); } DOM.addStandardDisposableListener(view, DOM.EventType.CLICK, (e: IMouseEvent) => { this._onDidClickOverrideElement.fire({ targetKey: element.setting.key, scope: element.overriddenScopeList[i] }); e.preventDefault(); e.stopPropagation(); }); } </ins> } // Remove tree attributes - sometimes overridden by tree - should be managed there

Discussion:
Issue Type: <bFeature Request</bTesting Just a thought: When I see "Modified in: Workspace" I might want to go there and check. I'd keep font and color as they are and add an underline and pointer cursor to "Workspace" on hover. VS Code version: Code - Insiders 1.27.0-insider (, 2018-08-29T05:12:15.247Z) OS version: Darwin x64 17.7.0 <!-- generated by issue reporter --
Good idea!
I would take a PR for this "Modified in: Workspace" - the word Workspace is underlined When clicked, it switches to the Workspace scope, and copies the setting key into the search bar, so the view is filtered to just that one setting
I'm interested in looking into this if that is alright.
Change:
_serviceBrand: undefined; private selectContainer!: HTMLElement; <ins> private inputContainer!: HTMLElement; </ins> private input!: IActiveCodeEditor; private toDispose: lifecycle.IDisposable[]; private conditionInput = '';

Discussion:
<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: -- isn't fixed <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.37.0 OS Version: Windows 10 !
This works just fine for me on OS X and Win10 with vscode insiders. Can you reproduce with latest vscode insiders !
Thanks. I tried and it is indeed fixed in the insider build. However, I can reproduce it for sure on the stable version. The fix should have been included in June update. (seems it was)
There might be some extension which you are using that is modiyfing css and is breaking this. Sorry but I can not reproduce this, either in stable and in insiders. Also no other user seems to be hitting this. Due to that I will close this issue. And yes the fix was included in the June update.
I find the key to reproduction now. Just put in the and you will see the bug.
Yes I acknowledge the bug. The issue is that the breakpoint widget is not updating as the editor font updates. The size of the widget updates, but the font should update as well. I am open to PR that fix this issue Code pointer
Will have a try
Things look more complicated than we expected.  doesn't feel right. The is of 40px height (with font size set to 16) ! It looks more reasonable if setting the height to 20px ! centering thing. The is centred by the styles of (its parent dom) while gets a hardcoded 8px ... !
yes I acknowledge it is not the nicest. Any improvements in that area would be appreciated.
I have gone too deep down the rabbit hole . Leaving it to whoever interested...
This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details . If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider. If you wonder what we are up to, please see our and guidelines. Thanks for your understanding and happy coding!

I understand this issue is not that important. But I don't agree this is out of scope . IMHO, it is at least a bug (although with very low priority).
Agree, let's reopen.
Attempted a PR () for this. Please have a look.
Verifier: Change the editor.fontSize, add a conditional breakpoint and make sure the text in the breakpoint widget is centered. Or can just try in VS COde insiders from Thursday and let us know how it behaves for him
Thank you! I confirm it is fixed in the insider build.
Thanks for letting us know. Adding verified label.
Change:
let result; let errorMessage: string | undefined; try { <del> result = await fetch(endpoint, { </del> <ins> result = await fetch(endpoint.toString(), { </ins> method: 'POST', headers: { <del> 'Content-Type': 'application/x-www-form-urlencoded', 'Content-Length': postData.length.toString() </del> <ins> 'Content-Type': 'application/x-www-form-urlencoded' </ins> }, body: postData });

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No No. The issue occurs in a built-in extension so extensions need to be enabled to see the issue. <!-- 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. --Version: 1.93.0-insider (Universal) Commit: Date: 2024-08-26T05:04:02.640Z Electron: 30.3.1 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0 Steps to Reproduce: VS Code behind a proxy server and make a call to the function from the package included with VS Code similar to the one below. After the changes listed in , we began seeing failures from the Microsoft Authentication extension with the following log entries at startup. We rely on that extension to allow another extension we developed internally to authenticate our users. After debugging into the extension source, I found that the issue was originating here. After reading through the previously mentioned pull request, I figured that the call was hanging because the new function was not handling proxy configurations the same way (a common issue in corporate settings). I pulled down VS Code, built from source and tested a change that resolves the issue. I'd like to open a pull request with the fix if you agree that there is a bug in this flow. System Information
will be exploring fixing this type of issue transparently.
This will be in Monday's Insiders build. Can you please give that a try when it drops so we know for a fact we've fixed the issue for you?
that fixed the issue. Thanks so much for the quick response to our problem!