Question:
If you "refresh" an item (with children) by calling and the item is not expanded, the method still gets called. should not be called until the item is expanded, otherwise potentially expensive operations can be run for no visible reason (since the children are hidden).
This could result in unexpected behavior. If an extension currently relies on to always update the children then there would be out-of-date tree items.
How would this result in unexpected behavior? If the tree item has not loaded its children, why should calling refresh on it force its children to load?
I'm concerned that some extension authors have come to depend on the current behavior to keep their internal tree structure updated. I suppose we can try it and see if there are any complaints.
I think a change like this would need to happen in the , as at the custom tree view level we have no knowledge of whether a node is currently expanded or not. Is this something you'd be interested in doing?
Not sure I follow. What describes is exactly how the AsyncDataTree works: children aren't resolved until the user expands the parent the first time.
I am looking for a way to call on the AsyncDataTree such that if the tree item passed in to is collapsed, it will: "invalidate" the children or the tree item and not actually call on that tree item rerender the tree item instead of: calling for the tree item rerendering the tree item
Oh I guess I was wrong, what I said only applies to the next level. But the first node is called with will always have its be called. We can maybe add an option here, or even change the default behavior as I see no reason for collapsed tree nodes to need a call.
any update here? This issue causes GitLens to request way more data than desired in multiple cases (before the user expands them that is).
Thank you!
Thanks for the nudge!
Maybe it's easier if you verify this one.
will verify.
FYI, I tested GitLens with this change (in today's insiders) and it looks good to me!

import { AsyncDataTree } from 'vs/base/browser/ui/tree/asyncDataTree'; import { IAsyncDataSource, ITreeNode, ITreeRenderer } from 'vs/base/browser/ui/tree/tree'; import { timeout } from 'vs/base/common/async'; <ins> import { Iterable } from 'vs/base/common/iterator'; </ins> interface Element { id: string;


Question:
If you "refresh" an item (with children) by calling and the item is not expanded, the method still gets called. should not be called until the item is expanded, otherwise potentially expensive operations can be run for no visible reason (since the children are hidden).
This could result in unexpected behavior. If an extension currently relies on to always update the children then there would be out-of-date tree items.
How would this result in unexpected behavior? If the tree item has not loaded its children, why should calling refresh on it force its children to load?
I'm concerned that some extension authors have come to depend on the current behavior to keep their internal tree structure updated. I suppose we can try it and see if there are any complaints.
I think a change like this would need to happen in the , as at the custom tree view level we have no knowledge of whether a node is currently expanded or not. Is this something you'd be interested in doing?
Not sure I follow. What describes is exactly how the AsyncDataTree works: children aren't resolved until the user expands the parent the first time.
I am looking for a way to call on the AsyncDataTree such that if the tree item passed in to is collapsed, it will: "invalidate" the children or the tree item and not actually call on that tree item rerender the tree item instead of: calling for the tree item rerendering the tree item
Oh I guess I was wrong, what I said only applies to the next level. But the first node is called with will always have its be called. We can maybe add an option here, or even change the default behavior as I see no reason for collapsed tree nodes to need a call.
any update here? This issue causes GitLens to request way more data than desired in multiple cases (before the user expands them that is).
Thank you!
Thanks for the nudge!
Maybe it's easier if you verify this one.
will verify.
FYI, I tested GitLens with this change (in today's insiders) and it looks good to me!

assert.deepStrictEqual(Array.from(container.querySelectorAll('.monaco-list-row')).map(e => e.textContent), ['a', 'b2']); }); <ins> test('issue #121567', async () => { const container = document.createElement('div'); const calls: Element[] = []; const dataSource = new class implements IAsyncDataSource<Element, Element> { hasChildren(element: Element): boolean { return !!element.children && element.children.length > 0; } async getChildren(element: Element) { calls.push(element); return element.children ?? Iterable.empty(); } }; const model = new Model({ id: 'root', children: [{ id: 'a', children: [{ id: 'aa' }] }] }); const a = model.get('a'); const tree = new AsyncDataTree<Element, Element>('test', container, new VirtualDelegate(), [new Renderer()], dataSource, { identityProvider: new IdentityProvider() }); tree.layout(200); await tree.setInput(model.root); assert.strictEqual(calls.length, 1, 'There should be a single getChildren call for the root'); assert(tree.isCollapsible(a), 'a is collapsible'); assert(tree.isCollapsed(a), 'a is collapsed'); await tree.updateChildren(a, false); assert.strictEqual(calls.length, 1, 'There should be no changes to the calls list, since a was collapsed'); assert(tree.isCollapsible(a), 'a is collapsible'); assert(tree.isCollapsed(a), 'a is collapsed'); const children = a.children; a.children = []; await tree.updateChildren(a, false); assert.strictEqual(calls.length, 1, 'There should still be no changes to the calls list, since a was collapsed'); assert(!tree.isCollapsible(a), 'a is no longer collapsible'); assert(tree.isCollapsed(a), 'a is collapsed'); a.children = children; await tree.updateChildren(a, false); assert.strictEqual(calls.length, 1, 'There should still be no changes to the calls list, since a was collapsed'); assert(tree.isCollapsible(a), 'a is collapsible again'); assert(tree.isCollapsed(a), 'a is collapsed'); await tree.expand(a); assert.strictEqual(calls.length, 2, 'Finally, there should be a getChildren call for a'); assert(tree.isCollapsible(a), 'a is still collapsible'); assert(!tree.isCollapsed(a), 'a is expanded'); }); </ins> });


Question:
If the knows which languages a user tried in their first day, it could unlock more specific questions to further improve the language onboarding experience. How though. tracks the edited count for languages that run surveys; which are the languages we care most about right now. Only issue is that the storage key isn't exported, so the doesn't know about it. any general thoughts on the idea, and best practices on how to make the storage keys known to the ces survey code; so they can be read and attached as params to the survey URL?
The CES code already has access to the same . Can't you copy the maps the surveys to storage service keys over to CES and read them from there?
Sure, was mainly worried that this creates some copy/pasta. Will take that approach for an initial pull request draft and gather feedback.
No worries. We can also extract the common code to a new file, sibling to those two.
are there verification steps for this?
Sorry that they are so complex and time-intensive. I can also verify that I see survey responses from insiders that include the language data. a fresh VS Code Insiders instance , ensure that you are in the treatment group a Java file and save it. VS Code open for 1 hour to trigger the new-user survey popup and click to open the survey that the URL it opened contains
Ok, see you in an hour!
The treatment service does not seem to like me, for some reason. Unmarking as verified for someone else to give it a shot. Note that you need to repeatedly open VS Code windows with new user-data-dir's until you get into the treatment.
Also attempted this but no survey after an hour. Confirmed I did get an initial
when the experiment enables the survey you should also get a event? Did that work?
Testing again
Worked! [redacted]&javaLang=1

import { Event } from 'vs/base/common/event'; const WAIT_TIME_TO_SHOW_SURVEY = 1000 * 60 * 60; // 1 hour <del> const MIN_WAIT_TIME_TO_SHOW_SURVEY = 1000 * 60 * 5; // 5 minutes </del> <ins> const MIN_WAIT_TIME_TO_SHOW_SURVEY = 1000 * 60 * 2; // 2 minutes </ins> const MAX_INSTALL_AGE = 1000 * 60 * 60 * 24; // 24 hours const REMIND_LATER_DELAY = 1000 * 60 * 60 * 4; // 4 hours const SKIP_SURVEY_KEY = 'ces/skipSurvey';


Question:
If the knows which languages a user tried in their first day, it could unlock more specific questions to further improve the language onboarding experience. How though. tracks the edited count for languages that run surveys; which are the languages we care most about right now. Only issue is that the storage key isn't exported, so the doesn't know about it. any general thoughts on the idea, and best practices on how to make the storage keys known to the ces survey code; so they can be read and attached as params to the survey URL?
The CES code already has access to the same . Can't you copy the maps the surveys to storage service keys over to CES and read them from there?
Sure, was mainly worried that this creates some copy/pasta. Will take that approach for an initial pull request draft and gather feedback.
No worries. We can also extract the common code to a new file, sibling to those two.
are there verification steps for this?
Sorry that they are so complex and time-intensive. I can also verify that I see survey responses from insiders that include the language data. a fresh VS Code Insiders instance , ensure that you are in the treatment group a Java file and save it. VS Code open for 1 hour to trigger the new-user survey popup and click to open the survey that the URL it opened contains
Ok, see you in an hour!
The treatment service does not seem to like me, for some reason. Unmarking as verified for someone else to give it a shot. Note that you need to repeatedly open VS Code windows with new user-data-dir's until you get into the treatment.
Also attempted this but no survey after an hour. Confirmed I did get an initial
when the experiment enables the survey you should also get a event? Did that work?
Testing again
Worked! [redacted]&javaLang=1

run: () => { sendTelemetry('accept'); this.telemetryService.getTelemetryInfo().then(info => { <del> this.openerService.open(URI.parse(`${this.productService.cesSurveyUrl}?o=${encodeURIComponent(platform)}&v=${encodeURIComponent(this.productService.version)}&m=${encodeURIComponent(info.machineId)}`)); </del> <ins> let surveyUrl = `${this.productService.cesSurveyUrl}?o=${encodeURIComponent(platform)}&v=${encodeURIComponent(this.productService.version)}&m=${encodeURIComponent(info.machineId)}`; const usedParams = this.productService.surveys ?.filter(surveyData => surveyData.surveyId && surveyData.languageId) // Counts provided by contrib/surveys/browser/languageSurveys .filter(surveyData => this.storageService.getNumber(`${surveyData.surveyId}.editedCount`, StorageScope.GLOBAL, 0) > 0) .map(surveyData => `${encodeURIComponent(surveyData.languageId)}Lang=1`) .join('&'); if (usedParams) { surveyUrl += `&${usedParams}`; } this.openerService.open(URI.parse(surveyUrl)); </ins> this.skipSurvey(); }); }


Question: When changing the default editor we show a in the quick pick to change this. The gear action by itself is not clear that it will immediately change the default and assume there would be another screen to confirm. ! Change the flow to match how you select different formatters to make it clearer/explicit. In the formatter case, there is a "Configure Default Formatter..." that is clear and indicates that user input is required on the next step. The same can be applied to default editors. ! cc

import { ContributedEditorInfo, ContributedEditorPriority, ContributionPointOptions, DEFAULT_EDITOR_ASSOCIATION, DiffEditorInputFactoryFunction, EditorAssociation, EditorAssociations, EditorInputFactoryFunction, editorsAssociationsSettingId, globMatchesResource, IEditorOverrideService, priorityToRank } from 'vs/workbench/services/editor/common/editorOverrideService'; import { IKeyMods, IQuickInputService, IQuickPickItem, IQuickPickSeparator } from 'vs/platform/quickinput/common/quickInput'; import { localize } from 'vs/nls'; <del> import { Codicon } from 'vs/base/common/codicons'; </del> import { INotificationService, Severity } from 'vs/platform/notification/common/notification'; import { ITelemetryService } from 'vs/platform/telemetry/common/telemetry'; import { registerSingleton } from 'vs/platform/instantiation/common/extensions';


Question: When changing the default editor we show a in the quick pick to change this. The gear action by itself is not clear that it will immediately change the default and assume there would be another screen to confirm. ! Change the flow to match how you select different formatters to make it clearer/explicit. In the formatter case, there is a "Configure Default Formatter..." that is clear and indicates that user input is required on the next step. The same can be applied to default editors. ! cc

export class EditorOverrideService extends Disposable implements IEditorOverrideService { readonly _serviceBrand: undefined; <ins> private static readonly configureDefaultID = 'promptOpenWith.configureDefault'; </ins> private _contributionPoints: Map<string | glob.IRelativePattern, ContributionPoints> = new Map<string | glob.IRelativePattern, ContributionPoints>(); private static readonly overrideCacheStorageID = 'editorOverrideService.cache'; private cache: Set<string> | undefined;


Question: When changing the default editor we show a in the quick pick to change this. The gear action by itself is not clear that it will immediately change the default and assume there would be another screen to confirm. ! Change the flow to match how you select different formatters to make it clearer/explicit. In the formatter case, there is a "Configure Default Formatter..." that is clear and indicates that user input is required on the next step. The same can be applied to default editors. ! cc

}); } <del> private mapContributionsToQuickPickEntry(resource: URI, group: IEditorGroup, alwaysUpdateSetting?: boolean) { </del> <ins> private mapContributionsToQuickPickEntry(resource: URI, group: IEditorGroup, showDefaultPicker?: boolean) { </ins> const currentEditor = firstOrDefault(group.findEditors(resource)); // If untitled, we want all contribution points let contributionPoints = resource.scheme === Schemas.untitled ? distinct(flatten(Array.from(this._contributionPoints.values())), (contrib) => contrib.editorInfo.id) : this.findMatchingContributions(resource);


Question: When changing the default editor we show a in the quick pick to change this. The gear action by itself is not clear that it will immediately change the default and assume there would be another screen to confirm. ! Change the flow to match how you select different formatters to make it clearer/explicit. In the formatter case, there is a "Configure Default Formatter..." that is clear and indicates that user input is required on the next step. The same can be applied to default editors. ! cc

return priorityToRank(b.editorInfo.priority) - priorityToRank(a.editorInfo.priority); } }); <del> const contribGroups: { defaults: Array<IQuickPickSeparator | IQuickPickItem>, optional: Array<IQuickPickSeparator | IQuickPickItem> } = { defaults: [ { type: 'separator', label: localize('editorOverride.picker.default', 'Defaults') } ], optional: [ { type: 'separator', label: localize('editorOverride.picker.optional', 'Optional') } ], }; </del> <ins> const quickPickEntries: Array<IQuickPickItem | IQuickPickSeparator> = []; </ins> // Get the matching contribtuions and call resolve whether they're active for the picker contributionPoints.forEach(contribPoint => { const isActive = currentEditor ? contribPoint.editorInfo.describes(currentEditor) : false; <del> const quickPickEntry = { </del> <ins> const quickPickEntry: IQuickPickItem = { </ins> id: contribPoint.editorInfo.id, label: contribPoint.editorInfo.label, description: isActive ? localize('promptOpenWith.currentlyActive', "Currently Active") : undefined, detail: contribPoint.editorInfo.detail ?? contribPoint.editorInfo.priority, <del> buttons: alwaysUpdateSetting ? [] : [{ iconClass: Codicon.gear.classNames, tooltip: localize('promptOpenWith.setDefaultTooltip', "Set as default editor for '{0}' files", extname(resource)) }], </del> }; <del> if (contribPoint.editorInfo.priority === ContributedEditorPriority.option) { contribGroups.optional.push(quickPickEntry); } else { contribGroups.defaults.push(quickPickEntry); } </del> <ins> quickPickEntries.push(quickPickEntry); </ins> }); <del> return [...contribGroups.defaults, ...contribGroups.optional]; </del> <ins> if (!showDefaultPicker) { const separator: IQuickPickSeparator = { type: 'separator' }; quickPickEntries.push(separator); const configureDefaultEntry = { id: EditorOverrideService.configureDefaultID, label: localize('promptOpenWith.configureDefault', "Configure default editor....") }; quickPickEntries.push(configureDefaultEntry); } return quickPickEntries; </ins> } <del> private async doPickEditorOverride(editor: IEditorInput, options: IEditorOptions | undefined, group: IEditorGroup, alwaysUpdateSetting?: boolean): Promise<[IEditorOptions, IEditorGroup | undefined] | undefined> { </del> <ins> private async doPickEditorOverride(editor: IEditorInput, options: IEditorOptions | undefined, group: IEditorGroup, showDefaultPicker?: boolean): Promise<[IEditorOptions, IEditorGroup | undefined] | undefined> { </ins> type EditorOverridePick = { readonly item: IQuickPickItem;


Question: When changing the default editor we show a in the quick pick to change this. The gear action by itself is not clear that it will immediately change the default and assume there would be another screen to confirm. ! Change the flow to match how you select different formatters to make it clearer/explicit. In the formatter case, there is a "Configure Default Formatter..." that is clear and indicates that user input is required on the next step. The same can be applied to default editors. ! cc

} // Text editor has the lowest priority because we <del> const editorOverridePicks = this.mapContributionsToQuickPickEntry(resource, group, alwaysUpdateSetting); </del> <ins> const editorOverridePicks = this.mapContributionsToQuickPickEntry(resource, group, showDefaultPicker); </ins> // Create editor override picker const editorOverridePicker = this.quickInputService.createQuickPick<IQuickPickItem>(); <del> const placeHolderMessage = alwaysUpdateSetting ? </del> <ins> const placeHolderMessage = showDefaultPicker ? </ins> localize('prompOpenWith.updateDefaultPlaceHolder', "Select new default editor for '{0}'", basename(resource)) : localize('promptOpenWith.placeHolder', "Select editor for '{0}'", basename(resource)); editorOverridePicker.placeholder = placeHolderMessage;


Question: When changing the default editor we show a in the quick pick to change this. The gear action by itself is not clear that it will immediately change the default and assume there would be another screen to confirm. ! Change the flow to match how you select different formatters to make it clearer/explicit. In the formatter case, there is a "Configure Default Formatter..." that is clear and indicates that user input is required on the next step. The same can be applied to default editors. ! cc

} // If asked to always update the setting then update it even if the gear isn't clicked <del> if (alwaysUpdateSetting && result?.item.id) { </del> <ins> if (showDefaultPicker && result?.item.id) { </ins> this.updateUserAssociations(`*${extname(resource)}`, result.item.id,); }


Question: When changing the default editor we show a in the quick pick to change this. The gear action by itself is not clear that it will immediately change the default and assume there would be another screen to confirm. ! Change the flow to match how you select different formatters to make it clearer/explicit. In the formatter case, there is a "Configure Default Formatter..." that is clear and indicates that user input is required on the next step. The same can be applied to default editors. ! cc

// options and group to use accordingly if (picked) { <ins> // If the user selected to configure default we trigger this picker again and tell it to show the default picker if (picked.item.id === EditorOverrideService.configureDefaultID) { return this.doPickEditorOverride(editor, options, group, true); } </ins> // Figure out target group let targetGroup: IEditorGroup | undefined; if (picked.keyMods?.alt || picked.keyMods?.ctrlCmd) {


Question: <!-- 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. --- VS Code Version: 1.56.0-insider OS Version: Windows 10 Steps to Reproduce: new blank notebook cells only are missing bottom padding: ! <!-- 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. --

collector.addRule(`.notebookOverlay .cell-list-container > .monaco-list > .monaco-scrollable-element > .monaco-list-rows > .monaco-list-row > .cell-inner-container { padding-top: ${CELL_TOP_MARGIN}px; }`); collector.addRule(`.notebookOverlay .cell-list-container > .monaco-list > .monaco-scrollable-element > .monaco-list-rows > .markdown-cell-row > .cell-inner-container { padding-bottom: ${MARKDOWN_CELL_BOTTOM_MARGIN}px; padding-top: ${MARKDOWN_CELL_TOP_MARGIN}px; }`); collector.addRule(`.notebookOverlay .cell-list-container > .monaco-list > .monaco-scrollable-element > .monaco-list-rows > .markdown-cell-row > .cell-inner-container.webview-backed-markdown-cell { padding: 0; }`); <del> collector.addRule(`.notebookOverlay .cell-list-container > .monaco-list > .monaco-scrollable-element > .monaco-list-rows > .markdown-cell-row > .webview-backed-markdown-cell.markdown-cell-edit-mode .cell.code { padding-top: ${MARKDOWN_CELL_TOP_MARGIN}px; }`); </del> <ins> collector.addRule(`.notebookOverlay .cell-list-container > .monaco-list > .monaco-scrollable-element > .monaco-list-rows > .markdown-cell-row > .webview-backed-markdown-cell.markdown-cell-edit-mode .cell.code { padding-bottom: ${MARKDOWN_CELL_BOTTOM_MARGIN}px; padding-top: ${MARKDOWN_CELL_TOP_MARGIN}px; }`); </ins> collector.addRule(`.notebookOverlay .output { margin: 0px ${CELL_RIGHT_MARGIN}px 0px ${CODE_CELL_LEFT_MARGIN + CELL_RUN_GUTTER}px; }`); collector.addRule(`.notebookOverlay .output { width: calc(100% - ${CODE_CELL_LEFT_MARGIN + CELL_RUN_GUTTER + CELL_RIGHT_MARGIN}px); }`);


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.56.2 OS Version: Darwin x64 19.6.0 I was confused by the QuickPick API as and were commented "This can be read and updated by the extension." while wasn't. Then I was trying to dispose QuickInput and create a new one to update items, but after I read the source code I found can be directly updated by extensions
verification: look at the PR. It updated a comment.

readonly onDidTriggerButton: Event<QuickInputButton>; /** <del> * Items to pick from. </del> <ins> * Items to pick from. This can be read and updated by the extension. </ins> */ items: readonly T[];


Question: Issue Type: <bBug</bI have a multi-root VSC workspace with three folders: A/ ./subfolderOfA In A/, there is a file and in there, there are the following settings: When I edit some file somewhere inside A/, it seems like this JSON schema file path is only properly resolved If I remove folders and from my multi-root workspace. Shouldn't this work? VS Code version: Code 1.56.2 (, 2021-05-12T17:13:13.157Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ bracket-pair-colorizer-20.2.0 xml2.5.1 tortoise-svn0.1.1 python2020.9. vscode-pylance2021.5.3 jupyter2021.6. cpptools1.3.1 code-spell-checker1.10.2 open-in-browser2.0.0 vscodeintellicode1.2.14 </details<details<summaryA/B Experiments</summary</details

fileMatch?: string[]; url?: string; schema?: any; <ins> folderUri?: string; </ins> }; export namespace SettingIds {


Question: Issue Type: <bBug</bI have a multi-root VSC workspace with three folders: A/ ./subfolderOfA In A/, there is a file and in there, there are the following settings: When I edit some file somewhere inside A/, it seems like this JSON schema file path is only properly resolved If I remove folders and from my multi-root workspace. Shouldn't this work? VS Code version: Code 1.56.2 (, 2021-05-12T17:13:13.157Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ bracket-pair-colorizer-20.2.0 xml2.5.1 tortoise-svn0.1.1 python2020.9. vscode-pylance2021.5.3 jupyter2021.6. cpptools1.3.1 code-spell-checker1.10.2 open-in-browser2.0.0 vscodeintellicode1.2.14 </details<details<summaryA/B Experiments</summary</details

jsonFoldingLimit = normalizeLimit(workspace.getConfiguration(SettingIds.editorSection, { languageId: 'json' }).get(SettingIds.foldingMaximumRegions)); jsoncFoldingLimit = normalizeLimit(workspace.getConfiguration(SettingIds.editorSection, { languageId: 'jsonc' }).get(SettingIds.foldingMaximumRegions)); <ins> const schemas: JSONSchemaSettings[] = []; </ins> const settings: Settings = { http: { proxy: httpSettings.get('proxy'),


Question: Issue Type: <bBug</bI have a multi-root VSC workspace with three folders: A/ ./subfolderOfA In A/, there is a file and in there, there are the following settings: When I edit some file somewhere inside A/, it seems like this JSON schema file path is only properly resolved If I remove folders and from my multi-root workspace. Shouldn't this work? VS Code version: Code 1.56.2 (, 2021-05-12T17:13:13.157Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ bracket-pair-colorizer-20.2.0 xml2.5.1 tortoise-svn0.1.1 python2020.9. vscode-pylance2021.5.3 jupyter2021.6. cpptools1.3.1 code-spell-checker1.10.2 open-in-browser2.0.0 vscodeintellicode1.2.14 </details<details<summaryA/B Experiments</summary</details

validate: { enable: configuration.get(SettingIds.enableValidation) }, format: { enable: configuration.get(SettingIds.enableFormatter) }, keepLines: { enable: configuration.get(SettingIds.enableKeepLines) }, <del> schemas: [], </del> <ins> schemas, </ins> resultLimit: resultLimit + 1, // ask for one more so we can detect if the limit has been exceeded jsonFoldingLimit: jsonFoldingLimit + 1, jsoncFoldingLimit: jsoncFoldingLimit + 1 } }; <del> const schemaSettingsById: { [schemaId: string]: JSONSchemaSettings } = Object.create(null); const collectSchemaSettings = (schemaSettings: JSONSchemaSettings[], folderUri?: Uri, isMultiRoot?: boolean) => { let fileMatchPrefix = undefined; if (folderUri && isMultiRoot) { fileMatchPrefix = folderUri.toString(); if (fileMatchPrefix[fileMatchPrefix.length - 1] === '/') { fileMatchPrefix = fileMatchPrefix.substr(0, fileMatchPrefix.length - 1); } } </del> <ins> const collectSchemaSettings = (schemaSettings: JSONSchemaSettings[], folderUri?: Uri) => { </ins> for (const setting of schemaSettings) { const url = getSchemaId(setting, folderUri); <del> if (!url) { continue; } let schemaSetting = schemaSettingsById[url]; if (!schemaSetting) { schemaSetting = schemaSettingsById[url] = { url, fileMatch: [] }; settings.json!.schemas!.push(schemaSetting); } const fileMatches = setting.fileMatch; if (Array.isArray(fileMatches)) { const resultingFileMatches = schemaSetting.fileMatch || []; schemaSetting.fileMatch = resultingFileMatches; const addMatch = (pattern: string) => { //  filter duplicates if (resultingFileMatches.indexOf(pattern) === -1) { resultingFileMatches.push(pattern); } }; for (const fileMatch of fileMatches) { if (fileMatchPrefix) { if (fileMatch[0] === '/') { addMatch(fileMatchPrefix + fileMatch); addMatch(fileMatchPrefix + '/*' + fileMatch); } else { addMatch(fileMatchPrefix + '/' + fileMatch); addMatch(fileMatchPrefix + '/*/' + fileMatch); } } else { addMatch(fileMatch); } } } if (setting.schema && !schemaSetting.schema) { schemaSetting.schema = setting.schema; </del> <ins> if (url) { const schemaSetting: JSONSchemaSettings = { url, fileMatch: setting.fileMatch, folderUri: folderUri?.toString(false), schema: setting.schema }; schemas.push(schemaSetting); </ins> } } }; <del> const folders = workspace.workspaceFolders; // merge global and folder settings. Qualify all file matches with the folder path. </del> const globalSettings = workspace.getConfiguration('json', null).get<JSONSchemaSettings[]>('schemas'); if (Array.isArray(globalSettings)) { <del> if (!folders) { collectSchemaSettings(globalSettings); } </del> <ins> collectSchemaSettings(globalSettings); </ins> } <ins> const folders = workspace.workspaceFolders; </ins> if (folders) { <del> const isMultiRoot = folders.length > 1; </del> for (const folder of folders) { <del> const folderUri = folder.uri; const schemaConfigInfo = workspace.getConfiguration('json', folderUri).inspect<JSONSchemaSettings[]>('schemas'); const folderSchemas = schemaConfigInfo!.workspaceFolderValue; if (Array.isArray(folderSchemas)) { collectSchemaSettings(folderSchemas, folderUri, isMultiRoot); </del> <ins> const schemaConfigInfo = workspace.getConfiguration('json', folder.uri).inspect<JSONSchemaSettings[]>('schemas'); if (schemaConfigInfo && Array.isArray(schemaConfigInfo.workspaceFolderValue)) { collectSchemaSettings(schemaConfigInfo.workspaceFolderValue, folder.uri); </ins> } <del> if (Array.isArray(globalSettings)) { collectSchemaSettings(globalSettings, folderUri, isMultiRoot); } </del> } } return settings;


Question: Issue Type: <bBug</bI have a multi-root VSC workspace with three folders: A/ ./subfolderOfA In A/, there is a file and in there, there are the following settings: When I edit some file somewhere inside A/, it seems like this JSON schema file path is only properly resolved If I remove folders and from my multi-root workspace. Shouldn't this work? VS Code version: Code 1.56.2 (, 2021-05-12T17:13:13.157Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ bracket-pair-colorizer-20.2.0 xml2.5.1 tortoise-svn0.1.1 python2020.9. vscode-pylance2021.5.3 jupyter2021.6. cpptools1.3.1 code-spell-checker1.10.2 open-in-browser2.0.0 vscodeintellicode1.2.14 </details<details<summaryA/B Experiments</summary</details

url = schema.schema.id || `vscode://schemas/custom/${encodeURIComponent(hash(schema.schema).toString(16))}`; } } else if (folderUri && (url[0] === '.' || url[0] === '/')) { <del> url = Uri.joinPath(folderUri, url).toString(); </del> <ins> url = Uri.joinPath(folderUri, url).toString(false); </ins> } return url; }


Question: Issue Type: <bBug</bI have a multi-root VSC workspace with three folders: A/ ./subfolderOfA In A/, there is a file and in there, there are the following settings: When I edit some file somewhere inside A/, it seems like this JSON schema file path is only properly resolved If I remove folders and from my multi-root workspace. Shouldn't this work? VS Code version: Code 1.56.2 (, 2021-05-12T17:13:13.157Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ bracket-pair-colorizer-20.2.0 xml2.5.1 tortoise-svn0.1.1 python2020.9. vscode-pylance2021.5.3 jupyter2021.6. cpptools1.3.1 code-spell-checker1.10.2 open-in-browser2.0.0 vscodeintellicode1.2.14 </details<details<summaryA/B Experiments</summary</details

- `schemas`: Configures association of file names to schema URL or schemas and/or associations of schema URL to schema content. - `fileMatch`: an array of file names or paths (separated by `/`). `*` can be used as a wildcard. Exclusion patterns can also be defined and start with '!'. A file matches when there is at least one matching pattern and the last matching pattern is not an exclusion pattern. - `url`: The URL of the schema, optional when also a schema is provided. <del> - `schema`: The schema content. </del> <ins> - `schema`: The schema content, optional - `folderUri`: If provided, the association is only used if the document is located in the given folder (directly or indirectly) </ins> - `resultLimit`: The max number of color decorators and outline symbols to be computed (for performance reasons) - `jsonFoldingLimit`: The max number of folding ranges to be computed for json documents (for performance reasons) - `jsoncFoldingLimit`: The max number of folding ranges to be computed for jsonc documents (for performance reasons)


Question: Issue Type: <bBug</bI have a multi-root VSC workspace with three folders: A/ ./subfolderOfA In A/, there is a file and in there, there are the following settings: When I edit some file somewhere inside A/, it seems like this JSON schema file path is only properly resolved If I remove folders and from my multi-root workspace. Shouldn't this work? VS Code version: Code 1.56.2 (, 2021-05-12T17:13:13.157Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ bracket-pair-colorizer-20.2.0 xml2.5.1 tortoise-svn0.1.1 python2020.9. vscode-pylance2021.5.3 jupyter2021.6. cpptools1.3.1 code-spell-checker1.10.2 open-in-browser2.0.0 vscodeintellicode1.2.14 </details<details<summaryA/B Experiments</summary</details

* A match succeeds when there is at least one pattern matching and last matching pattern does not start with '!'. */ fileMatch: string[]; <ins> /** * If provided, the association is only used if the validated document is located in the given folder (directly or indirectly) */ folderUri?: string; </ins> /* * The schema for the given URI. * If no schema is provided, the schema will be fetched with the schema request service (if available).


Question: Issue Type: <bBug</bI have a multi-root VSC workspace with three folders: A/ ./subfolderOfA In A/, there is a file and in there, there are the following settings: When I edit some file somewhere inside A/, it seems like this JSON schema file path is only properly resolved If I remove folders and from my multi-root workspace. Shouldn't this work? VS Code version: Code 1.56.2 (, 2021-05-12T17:13:13.157Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ bracket-pair-colorizer-20.2.0 xml2.5.1 tortoise-svn0.1.1 python2020.9. vscode-pylance2021.5.3 jupyter2021.6. cpptools1.3.1 code-spell-checker1.10.2 open-in-browser2.0.0 vscodeintellicode1.2.14 </details<details<summaryA/B Experiments</summary</details

}, "main": "./out/node/jsonServerMain", "dependencies": { <ins> "@vscode/l10n": "^0.0.11", </ins> "jsonc-parser": "^3.2.0", "request-light": "^0.7.0", <del> "vscode-json-languageservice": "^5.1.4", </del> <ins> "vscode-json-languageservice": "^5.2.0", </ins> "vscode-languageserver": "^8.1.0-next.6", <del> "vscode-uri": "^3.0.7", "@vscode/l10n": "^0.0.11" </del> <ins> "vscode-uri": "^3.0.7" </ins> }, "devDependencies": { "@types/mocha": "^9.1.1",


Question: Issue Type: <bBug</bI have a multi-root VSC workspace with three folders: A/ ./subfolderOfA In A/, there is a file and in there, there are the following settings: When I edit some file somewhere inside A/, it seems like this JSON schema file path is only properly resolved If I remove folders and from my multi-root workspace. Shouldn't this work? VS Code version: Code 1.56.2 (, 2021-05-12T17:13:13.157Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ bracket-pair-colorizer-20.2.0 xml2.5.1 tortoise-svn0.1.1 python2020.9. vscode-pylance2021.5.3 jupyter2021.6. cpptools1.3.1 code-spell-checker1.10.2 open-in-browser2.0.0 vscodeintellicode1.2.14 </details<details<summaryA/B Experiments</summary</details

fileMatch?: string[]; url?: string; schema?: JSONSchema; <ins> folderUri?: string; </ins> }


Question: Issue Type: <bBug</bI have a multi-root VSC workspace with three folders: A/ ./subfolderOfA In A/, there is a file and in there, there are the following settings: When I edit some file somewhere inside A/, it seems like this JSON schema file path is only properly resolved If I remove folders and from my multi-root workspace. Shouldn't this work? VS Code version: Code 1.56.2 (, 2021-05-12T17:13:13.157Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ bracket-pair-colorizer-20.2.0 xml2.5.1 tortoise-svn0.1.1 python2020.9. vscode-pylance2021.5.3 jupyter2021.6. cpptools1.3.1 code-spell-checker1.10.2 open-in-browser2.0.0 vscodeintellicode1.2.14 </details<details<summaryA/B Experiments</summary</details

uri = schema.schema.id || `vscode://schemas/custom/${index}`; } if (uri) { <del> languageSettings.schemas.push({ uri, fileMatch: schema.fileMatch, schema: schema.schema }); </del> <ins> languageSettings.schemas.push({ uri, fileMatch: schema.fileMatch, schema: schema.schema, folderUri: schema.folderUri }); </ins> } }); }


Question: Issue Type: <bBug</bI have a multi-root VSC workspace with three folders: A/ ./subfolderOfA In A/, there is a file and in there, there are the following settings: When I edit some file somewhere inside A/, it seems like this JSON schema file path is only properly resolved If I remove folders and from my multi-root workspace. Shouldn't this work? VS Code version: Code 1.56.2 (, 2021-05-12T17:13:13.157Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ bracket-pair-colorizer-20.2.0 xml2.5.1 tortoise-svn0.1.1 python2020.9. vscode-pylance2021.5.3 jupyter2021.6. cpptools1.3.1 code-spell-checker1.10.2 open-in-browser2.0.0 vscodeintellicode1.2.14 </details<details<summaryA/B Experiments</summary</details

resolved "https://registry.yarnpkg.com/request-light/-/request-light-0.7.0.tgz#885628bb2f8040c26401ebf258ec51c4ae98ac2a" integrity sha512-lMbBMrDoxgsyO+yB3sDcrDuX85yYt7sS8BfQd11jtbW/z5ZWgLZRcEGLsLoYw7I0WSUGQBs8CC8ScIxkTX1+6Q== <del> vscode-json-languageservice@^5.1.4: version "5.1.4" resolved "https://registry.yarnpkg.com/vscode-json-languageservice/-/vscode-json-languageservice-5.1.4.tgz#cbdb447f281dcd107705e7fe8fbfc0b71db7610d" integrity sha512-ROZ1ezYQUbq9b/07xYpHtZSyyhoUk3oTTGVAEr6bU1DKr8ELaz9fsDoHno34tKtHj/Tf3deQqfjQNGKdbRuvTw== </del> <ins> vscode-json-languageservice@^5.2.0: version "5.2.0" resolved "https://registry.yarnpkg.com/vscode-json-languageservice/-/vscode-json-languageservice-5.2.0.tgz#884b7f108be4310e3332167c3ea60ab17f03418c" integrity sha512-q8Rdhu2HEddRxvlhVqwh0cWmKK+OtyMB2xRhtqXEQ7cjb0iZ14madb90iJe9fCHPjoj9CGBrq6QzuOp8OE6XWg== </ins> dependencies: "@vscode/l10n" "^0.0.11" jsonc-parser "^3.2.0"


Question: Issue Type: <bBug</bI have a multi-root VSC workspace with three folders: A/ ./subfolderOfA In A/, there is a file and in there, there are the following settings: When I edit some file somewhere inside A/, it seems like this JSON schema file path is only properly resolved If I remove folders and from my multi-root workspace. Shouldn't this work? VS Code version: Code 1.56.2 (, 2021-05-12T17:13:13.157Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ bracket-pair-colorizer-20.2.0 xml2.5.1 tortoise-svn0.1.1 python2020.9. vscode-pylance2021.5.3 jupyter2021.6. cpptools1.3.1 code-spell-checker1.10.2 open-in-browser2.0.0 vscodeintellicode1.2.14 </details<details<summaryA/B Experiments</summary</details

} }; <del> const collectSchemaSettings = (schemaSettings: JSONSchemaSettings[], folderUri?: Uri) => { for (const setting of schemaSettings) { const url = getSchemaId(setting, folderUri); if (url) { const schemaSetting: JSONSchemaSettings = { url, fileMatch: setting.fileMatch, folderUri: folderUri?.toString(false), schema: setting.schema }; schemas.push(schemaSetting); </del> <ins> const collectSchemaSettings = (schemaSettings: JSONSchemaSettings[] | undefined, folderUri?: Uri) => { if (schemaSettings) { for (const setting of schemaSettings) { const url = getSchemaId(setting, folderUri); if (url) { const schemaSetting: JSONSchemaSettings = { url, fileMatch: setting.fileMatch, folderUri: folderUri?.toString(false), schema: setting.schema }; schemas.push(schemaSetting); } </ins> } } }; <del> const globalSettings = workspace.getConfiguration('json', null).get<JSONSchemaSettings[]>('schemas'); if (Array.isArray(globalSettings)) { collectSchemaSettings(globalSettings); </del> <ins> const schemaConfigInfo = workspace.getConfiguration('json', null).inspect<JSONSchemaSettings[]>('schemas'); if (schemaConfigInfo) { if (workspace.workspaceFile) { collectSchemaSettings(schemaConfigInfo.workspaceValue, workspace.workspaceFile); } collectSchemaSettings(schemaConfigInfo.globalValue); </ins> } const folders = workspace.workspaceFolders; if (folders) { for (const folder of folders) { const schemaConfigInfo = workspace.getConfiguration('json', folder.uri).inspect<JSONSchemaSettings[]>('schemas'); <del> if (schemaConfigInfo && Array.isArray(schemaConfigInfo.workspaceFolderValue)) { collectSchemaSettings(schemaConfigInfo.workspaceFolderValue, folder.uri); } </del> <ins> collectSchemaSettings(schemaConfigInfo?.workspaceFolderValue, folder.uri); </ins> } } return settings;


Question: Issue Type: <bBug</bI have a multi-root VSC workspace with three folders: A/ ./subfolderOfA In A/, there is a file and in there, there are the following settings: When I edit some file somewhere inside A/, it seems like this JSON schema file path is only properly resolved If I remove folders and from my multi-root workspace. Shouldn't this work? VS Code version: Code 1.56.2 (, 2021-05-12T17:13:13.157Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ bracket-pair-colorizer-20.2.0 xml2.5.1 tortoise-svn0.1.1 python2020.9. vscode-pylance2021.5.3 jupyter2021.6. cpptools1.3.1 code-spell-checker1.10.2 open-in-browser2.0.0 vscodeintellicode1.2.14 </details<details<summaryA/B Experiments</summary</details

} }; <del> const collectSchemaSettings = (schemaSettings: JSONSchemaSettings[] | undefined, folderUri?: Uri) => { </del> <ins> const collectSchemaSettings = (schemaSettings: JSONSchemaSettings[] | undefined, folderUri: Uri | undefined = undefined, settingsLocation = folderUri) => { </ins> if (schemaSettings) { for (const setting of schemaSettings) { <del> const url = getSchemaId(setting, folderUri); </del> <ins> const url = getSchemaId(setting, settingsLocation); </ins> if (url) { const schemaSetting: JSONSchemaSettings = { url, fileMatch: setting.fileMatch, folderUri: folderUri?.toString(false), schema: setting.schema }; schemas.push(schemaSetting);


Question: Issue Type: <bBug</bI have a multi-root VSC workspace with three folders: A/ ./subfolderOfA In A/, there is a file and in there, there are the following settings: When I edit some file somewhere inside A/, it seems like this JSON schema file path is only properly resolved If I remove folders and from my multi-root workspace. Shouldn't this work? VS Code version: Code 1.56.2 (, 2021-05-12T17:13:13.157Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ bracket-pair-colorizer-20.2.0 xml2.5.1 tortoise-svn0.1.1 python2020.9. vscode-pylance2021.5.3 jupyter2021.6. cpptools1.3.1 code-spell-checker1.10.2 open-in-browser2.0.0 vscodeintellicode1.2.14 </details<details<summaryA/B Experiments</summary</details

} }; <ins> const folders = workspace.workspaceFolders; </ins> const schemaConfigInfo = workspace.getConfiguration('json', null).inspect<JSONSchemaSettings[]>('schemas'); if (schemaConfigInfo) { <del> if (workspace.workspaceFile) { collectSchemaSettings(schemaConfigInfo.workspaceValue, workspace.workspaceFile); </del> <ins> if (schemaConfigInfo.workspaceValue && workspace.workspaceFile && folders && folders.length) { const settingsLocation = Uri.joinPath(workspace.workspaceFile, '..'); for (const folder of folders) { collectSchemaSettings(schemaConfigInfo.workspaceValue, folder.uri, settingsLocation); } </ins> } collectSchemaSettings(schemaConfigInfo.globalValue); } <del> const folders = workspace.workspaceFolders; </del> if (folders) { for (const folder of folders) { const schemaConfigInfo = workspace.getConfiguration('json', folder.uri).inspect<JSONSchemaSettings[]>('schemas');


Question: Issue Type: <bBug</bI have a multi-root VSC workspace with three folders: A/ ./subfolderOfA In A/, there is a file and in there, there are the following settings: When I edit some file somewhere inside A/, it seems like this JSON schema file path is only properly resolved If I remove folders and from my multi-root workspace. Shouldn't this work? VS Code version: Code 1.56.2 (, 2021-05-12T17:13:13.157Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ bracket-pair-colorizer-20.2.0 xml2.5.1 tortoise-svn0.1.1 python2020.9. vscode-pylance2021.5.3 jupyter2021.6. cpptools1.3.1 code-spell-checker1.10.2 open-in-browser2.0.0 vscodeintellicode1.2.14 </details<details<summaryA/B Experiments</summary</details

return settings; } <del> function getSchemaId(schema: JSONSchemaSettings, folderUri?: Uri): string | undefined { </del> <ins> function getSchemaId(schema: JSONSchemaSettings, settingsLocation?: Uri): string | undefined { </ins> let url = schema.url; if (!url) { if (schema.schema) { url = schema.schema.id || `vscode://schemas/custom/${encodeURIComponent(hash(schema.schema).toString(16))}`; } <del> } else if (folderUri && (url[0] === '.' || url[0] === '/')) { url = Uri.joinPath(folderUri, url).toString(false); </del> <ins> } else if (settingsLocation && (url[0] === '.' || url[0] === '/')) { url = Uri.joinPath(settingsLocation, url).toString(false); </ins> } return url; }


Question: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.56.2 OS Version: MacOS Catalina 10.15.6 Steps to Reproduce: VSCode Version any typescript file (for example in ) /Ctrl + Click on any native dom method, for example , there should be a error message popups ! I thinks this is caused by the wrong type definition file path in below code:

if (isWeb()) { // On web, treat absolute paths as pointing to standard lib files if (filepath.startsWith('/')) { <del> return vscode.Uri.joinPath(this.context.extensionUri, 'node_modules', 'typescript', 'lib', filepath.slice(1)); </del> <ins> return vscode.Uri.joinPath(this.context.extensionUri, 'dist', 'browser', 'typescript', filepath.slice(1)); </ins> } }


Question:
The recently remote indicate tooltip helps users to learn about the limited extension functionality when in virtual workspaces. That allows us to reserve the banner for information on the restricted mode and avoid the complicated sentences when restricted mode and virtual workspaces are on at the same time. While it is interesting information that is limited extension functionality when in virtual workspaces, it's IMO not that crucial to warrant a banner. Also there's nothing the user can do about it.
FYI

import { IWorkspaceTrustManagementService, IWorkspaceTrustRequestService, workspaceTrustToString } from 'vs/platform/workspace/common/workspaceTrust'; import { Extensions as WorkbenchExtensions, IWorkbenchContribution, IWorkbenchContributionsRegistry } from 'vs/workbench/common/contributions'; import { LifecyclePhase } from 'vs/workbench/services/lifecycle/common/lifecycle'; <del> import { Codicon, registerCodicon } from 'vs/base/common/codicons'; </del> <ins> import { Codicon } from 'vs/base/common/codicons'; </ins> import { ThemeColor } from 'vs/workbench/api/common/extHostTypes'; import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; import { ContextKeyExpr } from 'vs/platform/contextkey/common/contextkey';


Question:
The recently remote indicate tooltip helps users to learn about the limited extension functionality when in virtual workspaces. That allows us to reserve the banner for information on the restricted mode and avoid the complicated sentences when restricted mode and virtual workspaces are on at the same time. While it is interesting information that is limited extension functionality when in virtual workspaces, it's IMO not that crucial to warrant a banner. Also there's nothing the user can do about it.
FYI

import { LIST_WORKSPACE_UNSUPPORTED_EXTENSIONS_COMMAND_ID } from 'vs/workbench/contrib/extensions/common/extensions'; const BANNER_RESTRICTED_MODE = 'workbench.banner.restrictedMode'; <del> const BANNER_VIRTUAL_WORKSPACE = 'workbench.banner.virtualWorkspace'; const BANNER_VIRTUAL_AND_RESTRICTED = 'workbench.banner.virtualAndRestricted'; </del> const STARTUP_PROMPT_SHOWN_KEY = 'workspace.trust.startupPrompt.shown'; const BANNER_RESTRICTED_MODE_DISMISSED_KEY = 'workbench.banner.restrictedMode.dismissed'; <del> const BANNER_VIRTUAL_WORKSPACE_DISMISSED_KEY = 'workbench.banner.virtualWorkspace.dismissed'; const infoIcon = registerCodicon('workspace-banner-warning-icon', Codicon.info); </del> /* * Trust Request via Service UX handler


Question:
The recently remote indicate tooltip helps users to learn about the limited extension functionality when in virtual workspaces. That allows us to reserve the banner for information on the restricted mode and avoid the complicated sentences when restricted mode and virtual workspaces are on at the same time. While it is interesting information that is limited extension functionality when in virtual workspaces, it's IMO not that crucial to warrant a banner. Also there's nothing the user can do about it.
FYI

break; case 'Manage': this.workspaceTrustRequestService.cancelRequest(); <del> await this.commandService.executeCommand('workbench.trust.manage'); </del> <ins> await this.commandService.executeCommand(MANAGE_TRUST_COMMAND_ID); </ins> break; case 'Cancel': this.workspaceTrustRequestService.cancelRequest();


Question:
The recently remote indicate tooltip helps users to learn about the limited extension functionality when in virtual workspaces. That allows us to reserve the banner for information on the restricted mode and avoid the complicated sentences when restricted mode and virtual workspaces are on at the same time. While it is interesting information that is limited extension functionality when in virtual workspaces, it's IMO not that crucial to warrant a banner. Also there's nothing the user can do about it.
FYI

this.statusbarService.updateEntryVisibility(this.entryId, false); } <del> private getBannerItem(isInVirtualWorkspace: boolean, restrictedMode: boolean): IBannerItem | undefined { </del> <ins> private getBannerItem(restrictedMode: boolean): IBannerItem | undefined { </ins> <del> const dismissedVirtual = this.storageService.getBoolean(BANNER_VIRTUAL_WORKSPACE_DISMISSED_KEY, StorageScope.WORKSPACE, false); </del> const dismissedRestricted = this.storageService.getBoolean(BANNER_RESTRICTED_MODE_DISMISSED_KEY, StorageScope.WORKSPACE, false); <del> // all important info has been dismissed if (dismissedVirtual && dismissedRestricted) { return undefined; } // don't show restricted mode only banner if (dismissedRestricted && !isInVirtualWorkspace) { </del> <ins> // info has been dismissed if (dismissedRestricted) { </ins> return undefined; } <del> // don't show virtual workspace only banner if (dismissedVirtual && !restrictedMode) { return undefined; } const choose = (virtual: any, restricted: any, virtualAndRestricted: any) => { return (isInVirtualWorkspace && !dismissedVirtual) && (restrictedMode && !dismissedRestricted) ? virtualAndRestricted : ((isInVirtualWorkspace && !dismissedVirtual) ? virtual : restricted); }; const id = choose(BANNER_VIRTUAL_WORKSPACE, BANNER_RESTRICTED_MODE, BANNER_VIRTUAL_AND_RESTRICTED); const icon = choose(infoIcon, shieldIcon, infoIcon); const [virtualAriaLabel, restrictedModeAriaLabel, virtualAndRestrictedModeAriaLabel] = this.getBannerItemAriaLabels(); const ariaLabel = choose(virtualAriaLabel, restrictedModeAriaLabel, virtualAndRestrictedModeAriaLabel); const [virtualMessage, restrictedModeMessage, virtualAndRestrictedModeMessage] = this.getBannerItemMessages(); const message = choose(virtualMessage, restrictedModeMessage, virtualAndRestrictedModeMessage); const actions = choose( [ { label: localize('virtualBannerLearnMore', "Learn More"), href: 'https://aka.ms/vscode-virtual-workspaces' } ], </del> <ins> const actions = </ins> [ { label: localize('restrictedModeBannerManage', "Manage"), <del> href: 'command:workbench.trust.manage' </del> <ins> href: 'command:' + MANAGE_TRUST_COMMAND_ID </ins> }, { label: localize('restrictedModeBannerLearnMore', "Learn More"), href: 'https://aka.ms/vscode-workspace-trust' } <del> ], [ { label: localize('virtualAndRestrictedModeBannerManage', "Manage Trust"), href: 'command:workbench.trust.manage' }, { label: localize('virtualBannerLearnMore', "Learn More"), href: 'https://aka.ms/vscode-virtual-workspaces' } ] ); </del> <ins> ]; </ins> return { <del> id, icon, ariaLabel, message, </del> <ins> id: BANNER_RESTRICTED_MODE, icon: shieldIcon, ariaLabel: this.getBannerItemAriaLabels(), message: this.getBannerItemMessages(), </ins> actions, onClose: () => { <del> if (isInVirtualWorkspace) { this.storageService.store(BANNER_VIRTUAL_WORKSPACE_DISMISSED_KEY, true, StorageScope.WORKSPACE, StorageTarget.MACHINE); } </del> if (restrictedMode) { this.storageService.store(BANNER_RESTRICTED_MODE_DISMISSED_KEY, true, StorageScope.WORKSPACE, StorageTarget.MACHINE); }


Question:
The recently remote indicate tooltip helps users to learn about the limited extension functionality when in virtual workspaces. That allows us to reserve the banner for information on the restricted mode and avoid the complicated sentences when restricted mode and virtual workspaces are on at the same time. While it is interesting information that is limited extension functionality when in virtual workspaces, it's IMO not that crucial to warrant a banner. Also there's nothing the user can do about it.
FYI

}; } <del> private getBannerItemAriaLabels(): [string, string, string] { </del> <ins> private getBannerItemAriaLabels(): string { </ins> switch (this.workspaceContextService.getWorkbenchState()) { case WorkbenchState.EMPTY: <del> return [ localize('virtualBannerAriaLabelWindow', "Some features are not available because the current window is backed by a virtual file system. Use navigation keys to access banner actions."), localize('restrictedModeBannerAriaLabelWindow', "Restricted Mode is intended for safe code browsing. Trust this window to enable all features. Use navigation keys to access banner actions."), localize('virtualAndRestrictedModeBannerAriaLabelWindow', "Some features are not available because the current window is backed by a virtual file system and is not trusted. You can trust this window to enable some of these features. Use navigation keys to access banner actions.") ]; </del> <ins> return localize('restrictedModeBannerAriaLabelWindow', "Restricted Mode is intended for safe code browsing. Trust this window to enable all features. Use navigation keys to access banner actions."); </ins> case WorkbenchState.FOLDER: <del> return [ localize('virtualBannerAriaLabelFolder', "Some features are not available because the current folder is backed by a virtual file system. Use navigation keys to access banner actions."), localize('restrictedModeBannerAriaLabelFolder', "Restricted Mode is intended for safe code browsing. Trust this folder to enable all features. Use navigation keys to access banner actions."), localize('virtualAndRestrictedModeBannerAriaLabelFolder', "Some features are not available because the current folder is backed by a virtual file system and is not trusted. You can trust this folder to enable some of these features. Use navigation keys to access banner actions.") ]; </del> <ins> return localize('restrictedModeBannerAriaLabelFolder', "Restricted Mode is intended for safe code browsing. Trust this folder to enable all features. Use navigation keys to access banner actions."); </ins> case WorkbenchState.WORKSPACE: <del> return [ localize('virtualBannerAriaLabelWorkspace', "Some features are not available because the current workspace is backed by a virtual file system. Use navigation keys to access banner actions."), localize('restrictedModeBannerAriaLabelWorkspace', "Restricted Mode is intended for safe code browsing. Trust this workspace to enable all features. Use navigation keys to access banner actions."), localize('virtualAndRestrictedModeBannerAriaLabelWorkspace', "Some features are not available because the current workspace is backed by a virtual file system and is not trusted. You can trust this workspace to enable some of these features. Use navigation keys to access banner actions.") ]; </del> <ins> return localize('restrictedModeBannerAriaLabelWorkspace', "Restricted Mode is intended for safe code browsing. Trust this workspace to enable all features. Use navigation keys to access banner actions."); </ins> } } <del> private getBannerItemMessages(): [string, string, string] { </del> <ins> private getBannerItemMessages(): string { </ins> switch (this.workspaceContextService.getWorkbenchState()) { case WorkbenchState.EMPTY: <del> return [ localize('virtualBannerMessageWindow', "Some features are not available because the current workspace is backed by a virtual file system."), localize('restrictedModeBannerMessageWindow', "Restricted Mode is intended for safe code browsing. Trust this window to enable all features."), localize('virtualAndRestrictedModeBannerMessageWindow', "Some features are not available because the current window is backed by a virtual file system and is not trusted. You can trust this window to enable some of these features.") ]; </del> <ins> return localize('restrictedModeBannerMessageWindow', "Restricted Mode is intended for safe code browsing. Trust this window to enable all features."); </ins> case WorkbenchState.FOLDER: <del> return [ localize('virtualBannerMessageFolder', "Some features are not available because the current folder is backed by a virtual file system."), localize('restrictedModeBannerMessageFolder', "Restricted Mode is intended for safe code browsing. Trust this folder to enable all features."), localize('virtualAndRestrictedModeBannerMessageFolder', "Some features are not available because the current folder is backed by a virtual file system and is not trusted. You can trust this folder to enable some of these features.") ]; </del> <ins> return localize('restrictedModeBannerMessageFolder', "Restricted Mode is intended for safe code browsing. Trust this folder to enable all features."); </ins> case WorkbenchState.WORKSPACE: <del> return [ localize('virtualBannerMessageWorkspace', "Some features are not available because the current workspace is backed by a virtual file system."), localize('restrictedModeBannerMessageWorkspace', "Restricted Mode is intended for safe code browsing. Trust this workspace to enable all features."), localize('virtualAndRestrictedModeBannerMessageWorkspace', "Some features are not available because the current workspace is backed by a virtual file system and is not trusted. You can trust this workspace to enable some of these features.") ]; </del> <ins> return localize('restrictedModeBannerMessageWorkspace', "Restricted Mode is intended for safe code browsing. Trust this workspace to enable all features."); </ins> } }


Question:
The recently remote indicate tooltip helps users to learn about the limited extension functionality when in virtual workspaces. That allows us to reserve the banner for information on the restricted mode and avoid the complicated sentences when restricted mode and virtual workspaces are on at the same time. While it is interesting information that is limited extension functionality when in virtual workspaces, it's IMO not that crucial to warrant a banner. Also there's nothing the user can do about it.
FYI

text: trusted ? `$(shield)` : `$(shield) ${text}`, ariaLabel: ariaLabel, tooltip: toolTip, <del> command: 'workbench.trust.manage', </del> <ins> command: MANAGE_TRUST_COMMAND_ID, </ins> backgroundColor, color };


Question:
The recently remote indicate tooltip helps users to learn about the limited extension functionality when in virtual workspaces. That allows us to reserve the banner for information on the restricted mode and avoid the complicated sentences when restricted mode and virtual workspaces are on at the same time. While it is interesting information that is limited extension functionality when in virtual workspaces, it's IMO not that crucial to warrant a banner. Also there's nothing the user can do about it.
FYI

} private updateWorkbenchIndicators(trusted: boolean): void { <del> const isInVirtualWorkspace = isVirtualWorkspace(this.workspaceContextService.getWorkspace()); </del> const isEmptyWorkspace = this.workspaceContextService.getWorkbenchState() === WorkbenchState.EMPTY; <del> const bannerItem = this.getBannerItem(isInVirtualWorkspace, !trusted); </del> <ins> const bannerItem = this.getBannerItem(!trusted); </ins> if (!isEmptyWorkspace || this.showIndicatorsInEmptyWindow) { this.updateStatusbarEntry(trusted); if (bannerItem) { <del> if (!isInVirtualWorkspace) { if (!trusted) { this.bannerService.show(bannerItem); } else { this.bannerService.hide(BANNER_RESTRICTED_MODE); } } else { </del> <ins> if (!trusted) { </ins> this.bannerService.show(bannerItem); <ins> } else { this.bannerService.hide(BANNER_RESTRICTED_MODE); </ins> } } }


Question: Since profiles are removed, the jupyter extension will show their "run above/below" commands unless we put them back in the cell toolbar by default, so we should just disable this setting until we have a jupyter profile available that disables it

[ConsolidatedRunButton]: { description: nls.localize('notebook.consolidatedRunButton.description', "Control whether extra actions are shown in a dropdown next to the run button."), type: 'boolean', <del> default: true, </del> <ins> default: false, </ins> tags: ['notebookLayout'] }, [NotebookCellEditorOptionsCustomizations]: editorOptionsCustomizationSchema


Question:
Not sure if this is a German only problem <img width="440" alt="capture" src="https://user-"
This is probably a generic issue. Command should not get translated. Is there a way to ignore a substring of the localization string so that it doesn't get translated? I guess we could use interpolation...
This is a generic problem. Here's pseudo language: !
Any specific verification steps? I tried changing my display language (to German) but the workspace trust page doesn't seem localized yet: !
Verified this by looking at the language packs in the vscode-loc repo. It's currently in English but translations take some time.

[ localize('untrustedTasks', "Tasks are disabled"), localize('untrustedDebugging', "Debugging is disabled"), <del> localize('untrustedExtensions', "[{0} extensions](command:{1}) are disabled or have limited functionality", numExtensions, LIST_WORKSPACE_UNSUPPORTED_EXTENSIONS_COMMAND_ID) </del> <ins> localize('untrustedExtensions', "[{0} extensions]({1}) are disabled or have limited functionality", numExtensions, `command:${LIST_WORKSPACE_UNSUPPORTED_EXTENSIONS_COMMAND_ID}`) </ins> ] : [ localize('untrustedTasks', "Tasks are disabled"), localize('untrustedDebugging', "Debugging is disabled"), <del> numSettings ? localize('untrustedSettings', "[{0} workspace settings](command:{1}) are not applied", numSettings, 'settings.filterUntrusted') : localize('no untrustedSettings', "Workspace settings requiring trust are not applied"), localize('untrustedExtensions', "[{0} extensions](command:{1}) are disabled or have limited functionality", numExtensions, LIST_WORKSPACE_UNSUPPORTED_EXTENSIONS_COMMAND_ID) </del> <ins> numSettings ? localize('untrustedSettings', "[{0} workspace settings]({1}) are not applied", numSettings, 'command:settings.filterUntrusted') : localize('no untrustedSettings', "Workspace settings requiring trust are not applied"), localize('untrustedExtensions', "[{0} extensions]({1}) are disabled or have limited functionality", numExtensions, `command:${LIST_WORKSPACE_UNSUPPORTED_EXTENSIONS_COMMAND_ID}`) </ins> ]; this.renderLimitationsListElement(untrustedContainer, untrustedContainerItems, xListIcon.classNamesArray);


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Insiders OS Version: Mac Basically when i have a statusbar item (extension that contributes statusbar items), VS Code re-creates all of the statusbar items for all cells. This causes ALL statubar items in all cells to flicker (as its destroyed and re-created) & we also end up with duplicates. /cc Flickering UI Duplicate statusbar items See below (from latest VS Code Insiders, can also replicate in latest main branch) Note how we end up with two language pickers in statusbar. ! After the fix (re-use instead of re-creating & only create what we need): !
Thought I had squashed all of these. Thanks for the PR!
The power tools don't seem to provide line numbers anymore so I tried switching the language mode around to repro and couldn't so I'm not sure if that's good enough for verification
I think it's sufficient to mess around with it and not see any dupes. And there were random reports of dupes earlier and I haven't heard that in awhile.

import { disposableTimeout, Throttler } from 'vs/base/common/async'; import { CancellationTokenSource } from 'vs/base/common/cancellation'; import { Disposable, toDisposable } from 'vs/base/common/lifecycle'; <del> import { ICellVisibilityChangeEvent, NotebookVisibleCellObserver } from 'vs/workbench/contrib/notebook/browser/contrib/statusBar/notebookVisibleCellObserver'; </del> <ins> import { NotebookVisibleCellObserver } from 'vs/workbench/contrib/notebook/browser/contrib/statusBar/notebookVisibleCellObserver'; </ins> import { ICellViewModel, INotebookEditor, INotebookEditorContribution } from 'vs/workbench/contrib/notebook/browser/notebookBrowser'; import { registerNotebookContribution } from 'vs/workbench/contrib/notebook/browser/notebookEditorExtensions'; <del> import { NotebookViewModel } from 'vs/workbench/contrib/notebook/browser/viewModel/notebookViewModel'; </del> <ins> import { CellViewModel, NotebookViewModel } from 'vs/workbench/contrib/notebook/browser/viewModel/notebookViewModel'; </ins> import { INotebookCellStatusBarService } from 'vs/workbench/contrib/notebook/common/notebookCellStatusBarService'; import { INotebookCellStatusBarItemList } from 'vs/workbench/contrib/notebook/common/notebookCommon';


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Insiders OS Version: Mac Basically when i have a statusbar item (extension that contributes statusbar items), VS Code re-creates all of the statusbar items for all cells. This causes ALL statubar items in all cells to flicker (as its destroyed and re-created) & we also end up with duplicates. /cc Flickering UI Duplicate statusbar items See below (from latest VS Code Insiders, can also replicate in latest main branch) Note how we end up with two language pickers in statusbar. ! After the fix (re-use instead of re-creating & only create what we need): !
Thought I had squashed all of these. Thanks for the PR!
The power tools don't seem to provide line numbers anymore so I tried switching the language mode around to repro and couldn't so I'm not sure if that's good enough for verification
I think it's sufficient to mess around with it and not see any dupes. And there were random reports of dupes earlier and I haven't heard that in awhile.

} private _updateEverything(): void { <del> this._visibleCells.forEach(cell => cell.dispose()); this._visibleCells.clear(); this._updateVisibleCells({ added: this._observer.visibleCells, removed: [] }); </del> <ins> const newCells = this._observer.visibleCells.filter(cell => !this._visibleCells.has(cell.handle)); const visibleCellHandles = new Set(this._observer.visibleCells.map(item => item.handle)); const currentCellHandles = Array.from(this._visibleCells.keys()); const removedCells = currentCellHandles.filter(handle => !visibleCellHandles.has(handle)); const itemsToUpdate = currentCellHandles.filter(handle => visibleCellHandles.has(handle)); this._updateVisibleCells({ added: newCells, removed: removedCells.map(handle => ({ handle })) }); itemsToUpdate.forEach(handle => this._visibleCells.get(handle)?.update()); </ins> } <del> private _updateVisibleCells(e: ICellVisibilityChangeEvent): void { </del> <ins> private _updateVisibleCells(e: { added: CellViewModel[]; removed: { handle: number }[]; }): void { </ins> const vm = this._notebookEditor.viewModel; if (!vm) { return;


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Insiders OS Version: Mac Basically when i have a statusbar item (extension that contributes statusbar items), VS Code re-creates all of the statusbar items for all cells. This causes ALL statubar items in all cells to flicker (as its destroyed and re-created) & we also end up with duplicates. /cc Flickering UI Duplicate statusbar items See below (from latest VS Code Insiders, can also replicate in latest main branch) Note how we end up with two language pickers in statusbar. ! After the fix (re-use instead of re-creating & only create what we need): !
Thought I had squashed all of these. Thanks for the PR!
The power tools don't seem to provide line numbers anymore so I tried switching the language mode around to repro and couldn't so I'm not sure if that's good enough for verification
I think it's sufficient to mess around with it and not see any dupes. And there were random reports of dupes earlier and I haven't heard that in awhile.

this._register(this._cell.model.onDidChangeOutputs(() => this._updateSoon())); } <ins> public update(): void { this._updateSoon(); } </ins> private _updateSoon(): void { // Wait a tick to make sure that the event is fired to the EH before triggering status bar providers this._register(disposableTimeout(() => {


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Insiders OS Version: Mac Basically when i have a statusbar item (extension that contributes statusbar items), VS Code re-creates all of the statusbar items for all cells. This causes ALL statubar items in all cells to flicker (as its destroyed and re-created) & we also end up with duplicates. /cc Flickering UI Duplicate statusbar items See below (from latest VS Code Insiders, can also replicate in latest main branch) Note how we end up with two language pickers in statusbar. ! After the fix (re-use instead of re-creating & only create what we need): !
Thought I had squashed all of these. Thanks for the PR!
The power tools don't seem to provide line numbers anymore so I tried switching the language mode around to repro and couldn't so I'm not sure if that's good enough for verification
I think it's sufficient to mess around with it and not see any dupes. And there were random reports of dupes earlier and I haven't heard that in awhile.

override dispose() { super.dispose(); <ins> this._activeToken?.dispose(true); </ins> this._notebookViewModel.deltaCellStatusBarItems(this._currentItemIds, [{ handle: this._cell.handle, items: [] }]); this._currentItemLists.forEach(itemList => itemList.dispose && itemList.dispose());


Question:
Version: 1.58.0-insider Commit: Date: 2021-06-16T05:18:57.982Z Electron: 12.0.11 Chrome: 89.0.4389.128 14.16.0 V8: 8.9.255.25-electron.0 OS: Linux x64 5.11.0-18-generic After starting up VS Code I got a modal dialog telling me about an unusual line delimiter. It didn't tell me about the file this is about. ! After accepting to fix, I saw where the problem was ! I find the dialog too heavy, especially on startup. I would need to see the code to find out what's the issue here. E.g. in our case, this is in a test, so might be intended Maybe have a warning triage next to 'LF' in the status bar? When I click ignore for this file, how can I unignore the file?
I agree this is pretty weird. The prompt comes from a code editor contribution which executes only when a code editor widget is instantiated and shows the problematic file. I think that this normally works fine, but in this case I believe the problematic file was opened, the dialog was shown, and then the "Release Notes" editor opened under the prompt and changed the active editor from under the prompt. I agree with the feedback here, but I'm not sure what to do. Maybe we could make the "Release Notes" editor wait until all confirm dialogs have been closed before showing itself or that the workbench starts directly with that editor after a release? Regarding converting this to a passive indicator in the status bar: I don't think that would be wise. Having this unusual line terminator will lead to semantic tokens, jump to definition and all kind of language features to become off. Here is the background:
Maybe instead of a modal dialog this could be shown somewhere in the editor area? Almost like the trust banner but instead of showing to the top of the window, showing right above the editor but still inside the editor? ! As for release notes, I think we are investigating to move away from using an editor and using something else but I cannot find the issue now. Arguably this can happen in other cases too I guess, e.g. when I open a file which loads slow and I manage to open another editor over it?
Well, easiest fix is to add the file name into the dialog, I would argue then it doesn't really matter which editor is active.
PR is up to change the dialog just a bit (): !

import { IEditorContribution } from 'vs/editor/common/editorCommon'; import { ITextModel } from 'vs/editor/common/model'; import { IDialogService } from 'vs/platform/dialogs/common/dialogs'; <ins> import { basename } from 'vs/base/common/resources'; </ins> const ignoreUnusualLineTerminators = 'ignoreUnusualLineTerminators';


Question:
Version: 1.58.0-insider Commit: Date: 2021-06-16T05:18:57.982Z Electron: 12.0.11 Chrome: 89.0.4389.128 14.16.0 V8: 8.9.255.25-electron.0 OS: Linux x64 5.11.0-18-generic After starting up VS Code I got a modal dialog telling me about an unusual line delimiter. It didn't tell me about the file this is about. ! After accepting to fix, I saw where the problem was ! I find the dialog too heavy, especially on startup. I would need to see the code to find out what's the issue here. E.g. in our case, this is in a test, so might be intended Maybe have a warning triage next to 'LF' in the status bar? When I click ignore for this file, how can I unignore the file?
I agree this is pretty weird. The prompt comes from a code editor contribution which executes only when a code editor widget is instantiated and shows the problematic file. I think that this normally works fine, but in this case I believe the problematic file was opened, the dialog was shown, and then the "Release Notes" editor opened under the prompt and changed the active editor from under the prompt. I agree with the feedback here, but I'm not sure what to do. Maybe we could make the "Release Notes" editor wait until all confirm dialogs have been closed before showing itself or that the workbench starts directly with that editor after a release? Regarding converting this to a passive indicator in the status bar: I don't think that would be wise. Having this unusual line terminator will lead to semantic tokens, jump to definition and all kind of language features to become off. Here is the background:
Maybe instead of a modal dialog this could be shown somewhere in the editor area? Almost like the trust banner but instead of showing to the top of the window, showing right above the editor but still inside the editor? ! As for release notes, I think we are investigating to move away from using an editor and using something else but I cannot find the issue now. Arguably this can happen in other cases too I guess, e.g. when I open a file which loads slow and I manage to open another editor over it?
Well, easiest fix is to add the file name into the dialog, I would argue then it doesn't really matter which editor is active.
PR is up to change the dialog just a bit (): !

const result = await this._dialogService.confirm({ title: nls.localize('unusualLineTerminators.title', "Unusual Line Terminators"), message: nls.localize('unusualLineTerminators.message', "Detected unusual line terminators"), <del> detail: nls.localize('unusualLineTerminators.detail', "This file contains one or more unusual line terminator characters, like Line Separator (LS) or Paragraph Separator (PS).nnIt is recommended to remove them from the file. This can be configured via `editor.unusualLineTerminators`."), primaryButton: nls.localize('unusualLineTerminators.fix', "Fix this file"), secondaryButton: nls.localize('unusualLineTerminators.ignore', "Ignore problem for this file") </del> <ins> detail: nls.localize('unusualLineTerminators.detail', "The file '{0}' contains one or more unusual line terminator characters, like Line Separator (LS) or Paragraph Separator (PS).nnIt is recommended to remove them from the file. This can be configured via `editor.unusualLineTerminators`.", basename(model.uri)), primaryButton: nls.localize('unusualLineTerminators.fix', "Remove Unusual Line Terminators"), secondaryButton: nls.localize('unusualLineTerminators.ignore', "Ignore") </ins> }); if (!result.confirmed) {


Question:
<!-- 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. 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? 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

import { ExtHostDocuments } from 'vs/workbench/api/common/extHostDocuments'; import * as extHostTypeConverter from 'vs/workbench/api/common/extHostTypeConverters'; import * as types from 'vs/workbench/api/common/extHostTypes'; <del> import { checkProposedApiEnabled } from 'vs/workbench/services/extensions/common/extensions'; </del> import type * as vscode from 'vscode'; import { ExtHostCommentsShape, IMainContext, MainContext, CommentThreadChanges, CommentChanges } from './extHost.protocol'; import { ExtHostCommands } from './extHostCommands';


Question:
<!-- 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. 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? 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

private _state?: vscode.CommentThreadState; get state(): vscode.CommentThreadState { <del> checkProposedApiEnabled(this.extensionDescription, 'commentsResolvedState'); </del> return this._state!; } set state(newState: vscode.CommentThreadState) { <del> checkProposedApiEnabled(this.extensionDescription, 'commentsResolvedState'); </del> this._state = newState; this.modifications.state = newState; this._onDidUpdateCommentThread.fire();