jiebi/CodeConvo huggingface dataset:
Change:
"constant" ], "settings": { <del> "foreground": "#AB6526" </del> <ins> "foreground": "#9C5D27" </ins> } }, {

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

Discussion:
Testing in Firefox with de-ch (Swiss German) set. Open command palette and search for Remote Repositories commands :bug: The first command has a partly English, partly de-ch line under it ( and in English, seems to be de-ch translated) !
Hmm yeah it should look like this (Desktop screenshot) with the English strings next to the German strings. I think this is a bug in how I'm applying the translations... !
Just found out about these functions on the desktop side: Which seems to go through the manifest and turn some s into s. I followed up with to understand how this works.
This code was originally written by so I would ask him to know how this works.
Not quite, it was originally written by , but I'm happy to try and help. My understanding is that the code is taking a JSON object that looks like this: Together with another JSON object that looks like this: And produces a JSON object that looks like this by substituting all string values of the shape with their corresponding value:
I still see this on firefox: ! The first option's english translation still looks wrong? (tested on )
The first one is still wrong because of so we'll track that there. However, the rest now have the English string underneath which they use to not have, which means this is fixed and verified
Change:
this._slugCount = new Map<string, number>(); const engine = await this.getEngine(document.uri); <del> return engine.render(text); </del> <ins> return engine.renderer.render(this.tokenize(document, engine), this.md, {}); </ins> } public async parse(document: SkinnyTextDocument): Promise<Token[]> { <del> const UNICODE_NEWLINE_REGEX = /u2028|u2029/g; const { text, offset } = this.stripFrontmatter(document.getText()); </del> this.currentDocument = document.uri; this._slugCount = new Map<string, number>(); const engine = await this.getEngine(document.uri); <del> return engine.parse(text.replace(UNICODE_NEWLINE_REGEX, ''), {}).map(token => { if (token.map) { token.map[0] += offset; token.map[1] += offset; } return token; }); </del> <ins> return this.tokenize(document, engine); </ins> } private addLineNumberRenderer(md: any, ruleName: string): void {

Discussion:
<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: Windows 7 & Mac 10.14 (Only these 2 Tested) A user of my extension reports duplicate html elements in export markdown, I debug & find this issue as described in header. It doesn't affect the preview rendering, so I cannot tell the step to reproduce. But I can tell, it's reproducible when all extension (except mine) is disabled, and the issue is gone in extension debugging environment. Please find more details here: PS: My extension uses VSCode Markdown render instance to provide WYSIWYG export
Is is causing any use facing problems?
Not really, copy HTML used most in copy & paste to rich text editors, as I know, which could still render right result. Only matters if user cares about the excessive codes, or performance worries (for running many times)
We have two calls to markdown it: Render the markdown to html parse the markdown to a set of tokens Markdown it has an internal render method that takes a list of tokens instead: We could cache the tokens and use this api instead. Marking as help wanted. Here's where the two calls are:
, I am trying this one :)
Change:
}; extensionTips: { [id: string]: string; }; extensionImportantTips: { [id: string]: { name: string; pattern: string; }; }; <del> exeBasedExtensionTips: { [id: string]: string; }; </del> <ins> exeBasedExtensionTips: { [id: string]: any; }; </ins> extensionKeywords: { [extension: string]: string[]; }; extensionAllowedBadgeProviders: string[]; keymapExtensionTips: string[];

Discussion:
In the renderer we want to stay away from sync fs API calls to because each call will stop the VM from doing anything. We should try to use the async fs APIs. The code in question is:
What about ?
yes, I reported those at the same time I reported this one via
There about 20 files that I need to run the checks on (this will definitely grow). Assuming there are about 20 paths in the PATH env variable, that is about 400 file checks to make in the worst case scenario If I do all of this async, thats about 400 async calls made at the same time. This can have an adverse affect as well correct? Or it doesnt matter at all?
anything is better than doing it sync, especially if you are stat'ing 400 files which probably means that the user cannot do anything for a couple of 100ms. We have  that allows to batch resolve. my 2 cents: having to stat 400 files for a feature seems wrong to me, especially if this blocks a piece of UI from working properly. At the very minimum this should run in the background, maybe buffered and not block any UI from showing up.
Change:
const event = <T>{ ...data, <ins> token, </ins> waitUntil: (p: Promise<unknown>): void => { if (Object.isFrozen(thenables)) { throw new Error('waitUntil can NOT be called asynchronous');

Discussion:
continues Timeout and user-cancellation applies when calling -events. However, we don't expose that in the API and silently stop async-event delivery and ignore results. We could let extension know via
For some big repo, it is possible for LS to parse more then hundreds files (which takes long time), right now, this can't be cancelled since we (LS) don't get any cancellation token (hence, no cancellation request). vscode side acts like it is cancelled, but only front end (vscode) is cancelled, all the backends (LSP and LS) that are actually doing the work are not cancelled. so even if vscode code send new requests (since vscode side is cancelled), LSP/LS won't be able to respond (not all LS is designed to process concurrent requests especially requests that have potential to change LS states). so only front end cancellation won't help much overall experiences.
fyi - this is now a thing and ready for LSP adoption
Neat, thanks
I verified that the token is available on the events, but it wasn't clear to me how to cause a user cancellation of the save/rename/delete. Can this only be done if there's slow file system provider?
You can call of the event with a promise that never or slowly resolves. Eventually the UI shows a progress notification which allows to cancel. That cancel will propagate to the extension.
I have now also verified that the token properly reflects the cancel status.
Thanks!
Change:
max-height: 100%; aspect-ratio: 1/1; background-image: url('./letterpress-light.svg'); <del> background-size: 100%; </del> <ins> background-size: contain; </ins> background-position-x: center; background-repeat: no-repeat; }

Discussion:
Set a 2x2 layout and make the window smaller: <img width="1210" alt="image" src=""
Hmmm, points to: But I see nothing from you here actually, I wonder if it could possibly be the Electron 22 update?
Opening up for help from community if someone wants to investigate. Here is what it should look like when you go small: <img width="760" alt="image" src=""
Confirmed, this is coming from the Electron 22 update. I cannot see any changes to the CSS that would otherwise explain this, so either this is a bug in Chrome or we need to change the CSS to get the experience we want: The watermark should shrink when the available space gets little. Currently it seems to stay as it is. CSS is here:
Change:
.add_port_raw(&TunnelPort { port_number, protocol: Some(TUNNEL_PROTOCOL_AUTO.to_owned()), <ins> access_control: Some(privacy_to_tunnel_acl(PortPrivacy::Private)), </ins> ..Default::default() }) .await

Discussion:
Testing It shows the error's message, but doesn't make explicit that there was an error thrown. ! This is from:
Change:
test('Active/Visible Editor', async function () { const firstEditorOpen = onDidOpenNotebookEditor(); const resource = await utils.createRandomFile(undefined, undefined, '.nbdtest'); <del> const firstEditor = await vscode.window.showNotebookDocument(resource); </del> <ins> const document = await vscode.workspace.openNotebookDocument(resource); const firstEditor = await vscode.window.showNotebookDocument(document); </ins> await firstEditorOpen; assert.strictEqual(vscode.window.activeNotebookEditor, firstEditor); assert.strictEqual(vscode.window.visibleNotebookEditors.includes(firstEditor), true); <del> const secondEditor = await vscode.window.showNotebookDocument(resource, { viewColumn: vscode.ViewColumn.Beside }); </del> <ins> const secondEditor = await vscode.window.showNotebookDocument(document, { viewColumn: vscode.ViewColumn.Beside }); </ins> // There is no guarantee that when `showNotebookDocument` resolves, the active notebook editor is already updated correctly. // assert.strictEqual(secondEditor === vscode.window.activeNotebookEditor, true); assert.notStrictEqual(firstEditor, secondEditor);

Discussion:
The has been finalized with VS Code 1.68 (). If your extension was using the proposal, you should now switch to the finalized version of this API. In the majority of cases, this switch is as simple as: your extension to target VS Code in the new from your list of enabled API proposal. However there are few small bumps to be aware of: has been renamed . Please make sure to switch over to the new property name as part of this migrationWe did not finalize the version of that takes a uri. Instead you can use Here's a list of all current consumers of the old API proposal: [x] ms-vsliveshare.vsliveshare — [X] ms- — [x] Dot net interactive — [x] GitHub.codespaces — [x] ms- — If you own one of these extensions, please migrate to the finalized notebook editor API. Let me know once the new version of your extension is published and I will remove your extension from the list of api consumers
I am actually fine in ESLint. The dependency was because of notebook support in LSP and LSP already converted to the final version for the 8.x release of the LSP libs.
Thank you everyone who's checked off their extension so far! If you have, I plan to remove your extension from the list of API consumers in July. This will only start effecting the insiders builds of VS Code at first, but please let me know if you notice any issues
I'm working on the change for Codespaces and expect it to be in our next extension release (1.10.0) in a few days. I'll reply back once it's on the marketplace.
We just published GitHub Codespaces 1.10.0 with this change, so you should be able to remove our extension from the list of proposed API consumers.
Change:
dispose(toDispose); })); } <ins> const compoundRoot = this._options.compoundRoot; if (compoundRoot) { toDispose.push(compoundRoot.onDidSessionStop(() => this.terminate())); } </ins> } getId(): string {

Discussion:
Ever since I started using the new JS debugger, when running our top level target and then manually closing the code-oss window, the and targets remain: ! Eventually, maybe 1 minute later, the goes away, but the other one stays, I always have to manually disconnect from it. ! cc
This is because is set for the shared process and extension host, which allows them to reconnect when vscode is reloaded. Eventually js-debug in extension host gives up, but the shared process is using the previous Node debugger which doesn't give up. Both these are working as designed, this is kind of a downside of the compound launch configs in that there's no "compound stop".
Yeah, would actually LOVE a compound stop. Could this be a feature of compounds, & Meaning, if something like was set in the compound, all targets would share the same action, and I would see no actions.
We could add a attribute to the compound, however how would that work? Clicking stop on any of the compound sessions would send stop to all sessions? And it would never be rendered as dicsonnect?
Maybe compound launch configs could have a pseudo-root, which has a "stop" action that affects all individual configs? ` The compound config could have an option whether sessions can be stopped individually, or whether stopping one session is treated as stopping the whole set of configuration.
ok makes somewhat sense, the flaw of my proposel is that once compound starts 4 sessions those sessions are not related in any way. So adding a pseudo root might be smart. The pseudo root would not be rendered, and the pseudo root would remember the attribute. Here are code pointers for a PR. We should add the attribute and to the schema . Code pointer for the debug session to add the pseudo root stopAll smartness
I like both options.
This bug has been fixed in to 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 pallette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Please let's have the bot not do this for ourselves.
BTW, the bot's wording sounds wrong: in to the latest...
Much better, and I this attribute to our compound config. But the behavior partly confuses me and I opened
Change:
})); await this._createOriginalWebview(generateUuid(), this._model.original.resource); <ins> if (this._originalWebview) { this._modifiedResourceDisposableStore.add(this._originalWebview); } </ins> await this._createModifiedWebview(generateUuid(), this._model.modified.resource); <ins> if (this._modifiedWebview) { this._modifiedResourceDisposableStore.add(this._modifiedWebview); } </ins> await this.updateLayout(); }

Discussion:
Issue Type: <bBug</bRepro a notebook in the diff view (tested with the github issues notebook) down to another file bug In dev tools, see: VS Code version: Code - OSS Dev 1.55.0 (Commit unknown, Date unknown) OS version: Darwin x64 20.3.0 <details<summarySystem Info</summary </details<details<summaryExtensions (23)</summaryExtensionVersion ------ docs-view0.0.9 vscode-eslint2.1.14 EditorConfig0.16.4 vscode-pull-request-github0.23.1 svg1.4.5 template-string-converter0.4.7 git-graph1.29.0 vscode-language-pack-de1.54.1 vscode-dotnet-runtime1.0.0 vscode-edge-devtools1.1.3 python2021.2. jupyter2021.3. remote-containers0.163.0 remote-ssh0.64.0 remote-ssh-edit0.64.0 azure-account0.9.6 cpptools1.2.2 hexeditor1.4.0 vscode-github-issue-notebooks0.0.68 vscode-markdown-notebook0.0.14 debugger-for-chrome4.12.12 debugger-for-edge1.0.15 shader-toy0.10.15 </details<!-- generated by issue reporter --
I believe that webviews in diff editors are being leaked at the moment. For normal notebooks, I see the webview disposed of in the method: However I don't see the same in notebookTextDiffEditor
Hm, now I'm just more confused. It seems the webviews are not disposed of when the diff editor is closed (and is not fired on the either). However they are disposed of when another notebook diff editor is opened The root cause of this issue is that the webview is no longer in the dom but it also isn't disposed. We then try posting a message to it which causes an exception. Here's the call stack that triggers this error: !
I started to see leaks of recently, which is likely a regression, and probably in the logic.
Change:
"license": "MIT", "description": "Dependencies shared by all extensions", "dependencies": { <del> "typescript": "4.7.1-rc" </del> <ins> "typescript": "4.7" </ins> }, "scripts": { "postinstall": "node ./postinstall.mjs"

Discussion:
Tracks shipping TypeScript 4.7 in VS Code See for details
/verified Insiders shows this for me: !
Change:
const folderPath = folder ? this.labelService.getUriLabel(folder.uri) : ''; const dirty = editor?.isDirty() && !editor.isSaving() ? WindowTitle.TITLE_DIRTY : ''; const appName = this.productService.nameLong; <del> const separator = this.configurationService.getValue<string>('window.titleSeparator'); const titleTemplate = this.configurationService.getValue<string>('window.title'); </del> <ins> const separator = this.configurationService.getValue<string>(WindowSettingNames.titleSeparator); const titleTemplate = this.configurationService.getValue<string>(WindowSettingNames.title); </ins> return template(titleTemplate, { activeEditorShort,

Discussion:
Testing I think we will soon turn command center on by default. What is the impact on then? I see we are only showing the full title in the hover now, but I wonder if we need another setting (?) so that users still can configure what we show in the command center? ! Or maybe we should find a way to show the even in the command center with ellipsis if overflowing. //cc
Seems reasonable to me
Enabling the command centre removes my custom window title, showing the full path of the currently focussed editor. I find this very useful especially when there are files with the same name but in different directories. Can't the command centre show the full custom window title (without having to hover over it)? Without this, I would permanently disable it.
We can say the default is different but a customisation is honoured
To verify enable command center configure and/or validate that any customization is picked up by the CC reset above settings validate that the CC uses a default
Any reason we wouldn't also apply this with the default setting? My worry is that when we eventually make command center on by default, the setting would basically not work until you change it? I think it looks good when enabled even with default setting: !
The idea is that the CC shows an affordance to do something, like "Search vscode" - we replaced "search" with the icon which watered this down a bit. The worry is that the more title-stuff we put here the less likely it is that folks understand this as affordance
Change:
this.tocTreeContainer = DOM.append(parent, $('.settings-toc-container')); this.tocTree = this._register(this.instantiationService.createInstance(TOCTree, <del> DOM.append(this.tocTreeContainer, $('.settings-toc-wrapper')), </del> <ins> DOM.append(this.tocTreeContainer, $('.settings-toc-wrapper', { 'role': 'navigation', 'aria-label': localize('settings', "Settings"), })), </ins> this.viewState)); this._register(this.tocTree.onDidChangeFocus(e => {

Discussion:
When I'm navigating the settings in the settings editor, there's no way to move focus back to the TOC tree. (Other than shift+tabbing through all the settings) To repro: the settings editor down for a bit way to go to TOC on the left is to shift + tab all the way back to the top
How do I get back to the TOC without shift+tab all the way back up to the top?
if you're using a screen reader, then you can use browse mode to navigate to the previous landmark, and that will focus the TOC. But I have been working on adding a default keybinding to it.
Actually now that I think about it, it's a duplicate of
Change:
if (item.type !== 'separator') { const previous = index && inputElements[index - 1]; const saneLabel = item.label && item.label.replace(/r?n/g, ' '); <ins> const saneSortLabel = parseLabelWithIcons(saneLabel).text.trim(); </ins> const saneMeta = item.meta && item.meta.replace(/r?n/g, ' '); const saneDescription = item.description && item.description.replace(/r?n/g, ' '); const saneDetail = item.detail && item.detail.replace(/r?n/g, ' ');

Discussion:
Create or Checkout a PR Click on the branch indicator in the status bar Type Observe that doesn't show in top position Not sure what changed, but this used to work reliably until today, this was the main way I used to go back to the branch: <img width="1078" alt="image" src="https://user-"
We have an icon to the quick pick items but I would like to think that this did not break search. Will investigate.