Question:
When running VS Code (or the Monaco editor) all theme colors are exposed as CSS variables. That means components don’t need to use JavaScript to read and set colors but can simply rely on CSS. When a theme changes, the variable values automatically update. Also, with CSS variables you have less code and everything in one place. The (long) list below is all users of . Those that only set/update colors are candidates for adopting CSS variables The names of the CSS variables can be "derived" with the following logic the theme color id and replace dots with slashes For instance the color id is exposed as CSS variables . Find a sample adoption in this commit: [ ] [ ] [x] [x] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x]
Hi, is this issue still up for grabs? I would like to be assigned to one of the bullets.
Yep! Just feel free to grab whichever one you want and open a PR for it :)
Hi! I would like to grab
Hi How did you linked your PR in every line of the description in this issue? I am not able to edit the description and I opened a PR for 12 hours ago. I guess edited the description to add your PR but not mine?
Maybe I mentioned this issue in the pr?
Yes, I was just wondering if there was an automated way of doing this, but I dont think so. Thank you!
I wrote a small helper that generates dynamic CSS rules but with the css variables filled in: You can use this for simple cases. Hopefully, it prevents some typos. The code is at:
Terminal is done, the following are intentional exceptions: We need to pull the color into TS to pass to as it uses it in canvas calls. We need to apply 0.5 opacity to the resolved color for the background, using won't work as it will fade the text.
Tunnel view, comments, and tree view are done.
what is the recommendation when more than the color is part of a ? To give an example: Here, we conditionally make an element if we have a . We cannot just blindly move that over to CSS because we then lose the check for the color.
I don't know. Has to stay in code....
can I listen to a change for a color key via theme service to conditionally toggle a class based on a color being defined or not?
Yes, and
If anyone else is still working on this, you can get completions with this handy extension
What is the recommendation if I have to hardcode a codicon css, for eg., I am deriving the codicon class programatically as follows If I have to move this to CSS then I have to hardcode the codicon class as follows Is it ok to hardcode codicons like this?
Looking at where verifiedPublisherThemeIcon is used, it's always in a dom node that also has the class . Better avoid the codicon class name, but use
Interesting issue where a migration to CSS variable caused a bug (). It looks like some visual behaviour is defined by the OS/runtime and not by default user agent CSS to fallback to. So if your CSS variable ends up as , you get some default (?) and the result is that the OS styling is disabled. Relevant SO for my case:
I looked over mine again and they are all there still intentionally: I don't think we can get the same effect of in CSS using the variable. Same as above. This is needed as the color is handed off to
please check those occurrences anyways so that we can remove them from the todo list
For , I couldn't find references to . For , we use the RGB values from the foreground var and we use a custom alpha. Since this only applies to the text, I don't think that there's a CSS-only equivalent. We could create a new var for this or just leave this as is; I'm not sure what's best in this case.
you're setting there so you can probably use a plain style, unless the element also has a background color as that would also apply there.
The element also has links, which have a normal alpha, so then the link opacity is affected.
you could have another rule with higher specificity that re-applies the link color?
For you could define a new (terminal hover specific) color. The default value of the color can express that it is a function of To access a color value use
As discussed in standup, tabs have quite an involved CSS ruling that involves not only colors but also other properties. I would like to keep it this way via and not invent various class names to get a similar effect to make maintenance easier there.
Closing this as I believe we are done here

this._domNode.title = value; } } <del> registerThemingParticipant((theme: IColorTheme, collector: ICssStyleCollector) => { const editorBackgroundColor = theme.getColor(editorBackground)?.transparent(0.7); // Lightbulb Icon const editorLightBulbForegroundColor = theme.getColor(editorLightBulbForeground); if (editorLightBulbForegroundColor) { collector.addRule(` .monaco-editor .contentWidgets ${Codicon.lightBulb.cssSelector} { color: ${editorLightBulbForegroundColor}; background-color: ${editorBackgroundColor}; }`); } // Lightbulb Auto Fix Icon const editorLightBulbAutoFixForegroundColor = theme.getColor(editorLightBulbAutoFixForeground); if (editorLightBulbAutoFixForegroundColor) { collector.addRule(` .monaco-editor .contentWidgets ${Codicon.lightbulbAutofix.cssSelector} { color: ${editorLightBulbAutoFixForegroundColor}; background-color: ${editorBackgroundColor}; }`); } }); </del>


Question: We very likely do not need to ship all of this in the web bits: This was already once done before in , and when dependencies got renamed this was once again forgotten about.

# This makes sure the model is included in the package !@vscode/vscode-languagedetection/model/** <ins> # Ensure only the required telemetry pieces are loaded in web to reduce bundle size @microsoft/1ds-core-js/** @microsoft/1ds-post-js/** @microsoft/applicationinsights-core-js/** @microsoft/applicationinsights-shims/** !@microsoft/1ds-core-js/dist/ms.core.min.js !@microsoft/1ds-post-js/dist/ms.post.min.js !@microsoft/applicationinsights-core-js/browser/applicationinsights-core-js.min.js !@microsoft/applicationinsights-shims/dist/umd/applicationinsights-shims.min.js </ins>


Question:
+F to open the editor find widget. Focus should be on the find input box. case-sensitive search. to the case-sensitive search button. :bug: Keyboard focus is on that element, but it's not clear that keyboard focus is on that element. !
works fine on my machine with Light+ and Dark+ theme, what theme are you using? ! !
Thanks! I guess the problem depends on the theme. The problem seems to occur on at least Quiet Light, Solarized Light, and Monokai.
Can confirm the the issue in those themes on my windows machine. I never sent a pull request to vscode but that seems easy to solve, the question is what highlight color would fit best each theme, i might take a look later unless there are some rules about how to set some of the theme colors... the colors effecting this seem to be "focusBorder" and "inputOption.activeBorder" I would love to offer some new colors later today/tomorrow and pull request them
I propose giving a bit of contrast to the "focusBorder" I think that focus border should have a bit of contrast from background as this is marking elements the user needs to spot quickly, even in themes with less contrast light quiet light i think this is best to increase contrast in those areas, this is only showing for elements put in focus and wont change the feeling of the theme by much. Here are the new colors i propose and will commit and pull request later if those look acceptable For Quiet Light: ! For Solarized Light: ! For Monokai: !

"pickerGroup.foreground": "#75715E", "input.background": "#414339", "inputOption.activeBorder": "#75715E", <del> "focusBorder": "#75715E", </del> <ins> "focusBorder": "#99947c", </ins> "editorWidget.background": "#1e1f1c", "debugToolBar.background": "#1e1f1c", "diffEditor.insertedTextBackground": "#4b661680", // middle of #272822 and #a6e22e


Question:
+F to open the editor find widget. Focus should be on the find input box. case-sensitive search. to the case-sensitive search button. :bug: Keyboard focus is on that element, but it's not clear that keyboard focus is on that element. !
works fine on my machine with Light+ and Dark+ theme, what theme are you using? ! !
Thanks! I guess the problem depends on the theme. The problem seems to occur on at least Quiet Light, Solarized Light, and Monokai.
Can confirm the the issue in those themes on my windows machine. I never sent a pull request to vscode but that seems easy to solve, the question is what highlight color would fit best each theme, i might take a look later unless there are some rules about how to set some of the theme colors... the colors effecting this seem to be "focusBorder" and "inputOption.activeBorder" I would love to offer some new colors later today/tomorrow and pull request them
I propose giving a bit of contrast to the "focusBorder" I think that focus border should have a bit of contrast from background as this is marking elements the user needs to spot quickly, even in themes with less contrast light quiet light i think this is best to increase contrast in those areas, this is only showing for elements put in focus and wont change the feeling of the theme by much. Here are the new colors i propose and will commit and pull request later if those look acceptable For Quiet Light: ! For Solarized Light: ! For Monokai: !

} ], "colors": { <del> "focusBorder": "#A6B39B", </del> <ins> "focusBorder": "#9769dc", </ins> "pickerGroup.foreground": "#A6B39B", "pickerGroup.border": "#749351", "list.activeSelectionForeground": "#6c6c6c",


Question:
+F to open the editor find widget. Focus should be on the find input box. case-sensitive search. to the case-sensitive search button. :bug: Keyboard focus is on that element, but it's not clear that keyboard focus is on that element. !
works fine on my machine with Light+ and Dark+ theme, what theme are you using? ! !
Thanks! I guess the problem depends on the theme. The problem seems to occur on at least Quiet Light, Solarized Light, and Monokai.
Can confirm the the issue in those themes on my windows machine. I never sent a pull request to vscode but that seems easy to solve, the question is what highlight color would fit best each theme, i might take a look later unless there are some rules about how to set some of the theme colors... the colors effecting this seem to be "focusBorder" and "inputOption.activeBorder" I would love to offer some new colors later today/tomorrow and pull request them
I propose giving a bit of contrast to the "focusBorder" I think that focus border should have a bit of contrast from background as this is marking elements the user needs to spot quickly, even in themes with less contrast light quiet light i think this is best to increase contrast in those areas, this is only showing for elements put in focus and wont change the feeling of the theme by much. Here are the new colors i propose and will commit and pull request later if those look acceptable For Quiet Light: ! For Solarized Light: ! For Monokai: !

"colors": { // Base // "foreground": "", <del> "focusBorder": "#D3AF86", </del> <ins> "focusBorder": "#b49471", </ins> // "contrastActiveBorder": "", // "contrastBorder": "", // "widget.shadow": "",


Question: open vscode for web on macOS ctrl+click into a tab that is not active context menu opens but also the tab opens fyi this is similar to and requires the same fix. Interestingly on Electron this does not seem to be an issue, maybe produces context menu event in Electron but not in Web?

const handleTitleClickOrTouch = (e: MouseEvent | GestureEvent): void => { let target: HTMLElement; if (e instanceof MouseEvent) { <del> if (e.button !== 0 || (isMacintosh && e.ctrlKey)) { return undefined; // only for left mouse click (ctrl+click on macos is right-click) </del> <ins> if (e.button !== 0 /* middle/right mouse button */ || (isMacintosh && e.ctrlKey /* macOS context menu */)) { return undefined; </ins> } target = e.target as HTMLElement;


Question: open vscode for web on macOS ctrl+click into a tab that is not active context menu opens but also the tab opens fyi this is similar to and requires the same fix. Interestingly on Electron this does not seem to be an issue, maybe produces context menu event in Electron but not in Web?

const handleClickOrTouch = (e: MouseEvent | GestureEvent, preserveFocus: boolean): void => { tab.blur(); // prevent flicker of focus outline on tab until editor got focus <del> if (e instanceof MouseEvent && e.button !== 0) { </del> <ins> if (e instanceof MouseEvent && (e.button !== 0 /* middle/right mouse button */ || (isMacintosh && e.ctrlKey /* macOS context menu */))) { </ins> if (e.button === 1) { e.preventDefault(); // required to prevent auto-scrolling (https://github.com/microsoft/vscode/issues/16690) } <del> return undefined; // only for left mouse click </del> <ins> return undefined; </ins> } if (this.originatesFromTabActionBar(e)) {


Question:
When rendering Markdown preview, Unicode newline characters U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR are replaced with an empty string at the source preprocessing stage. This behavior was introduced in to but it breaks the document in multiple ways: double-click word selection does not work as expected, screen readers may announce the text incorrectly, line wrapping and hyphenation does not work correctly, markdown-it plugins that rely on or may work incorrectly, even linkify fails: and so on. Since then it was fixed at the markdown-it side, and is no longer needed: It would be better to revert this change, and keep the Markdown source as is before feeding it to the parser. Steps to reproduce: a Markdown document like this: preview: Expected result: LS and PS are displayed as is, links end at Unicode newlines. Actual result: no Unicode newline characters displayed, links also consume the immediately following word. <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: WindowsNT x64 10.0.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!

import { WebviewResourceProvider } from './util/resources'; import { isOfScheme, Schemes } from './util/schemes'; <del> const UNICODE_NEWLINE_REGEX = /u2028|u2029/g; </del> /** * Adds begin line index to the output via the 'data-line' data attribute. */


Question:
When rendering Markdown preview, Unicode newline characters U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR are replaced with an empty string at the source preprocessing stage. This behavior was introduced in to but it breaks the document in multiple ways: double-click word selection does not work as expected, screen readers may announce the text incorrectly, line wrapping and hyphenation does not work correctly, markdown-it plugins that rely on or may work incorrectly, even linkify fails: and so on. Since then it was fixed at the markdown-it side, and is no longer needed: It would be better to revert this change, and keep the Markdown source as is before feeding it to the parser. Steps to reproduce: a Markdown document like this: preview: Expected result: LS and PS are displayed as is, links end at Unicode newlines. Actual result: no Unicode newline characters displayed, links also consume the immediately following word. <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: WindowsNT x64 10.0.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!

private _tokenizeString(text: string, engine: MarkdownIt) { this._resetSlugCount(); <del> return engine.parse(text.replace(UNICODE_NEWLINE_REGEX, ''), {}); </del> <ins> return engine.parse(text, {}); </ins> } private _resetSlugCount(): void {


Question:
Does this issue occur when all extensions are disabled?: No VS Code Version: 1.73.1 OS Version: Windows_NT x64 10.0. Steps to Reproduce: ! to the extension bar. to hover some items. Some one may not show the default scroll bar, but the problem is exists. ! I have tried to fix it. It seems caused by the visual bug from the issue . The scroll bar will show when the content is too long. This solution is great, but it causes another little bug in the screenshot. I think it's unwise to remove the tag, so I tried another way, just add to the tag : ! I'll make a PR after this issue has submitted.
I can't reproduce this srollbar for all extensions in the list: !
This bug is not 100% recurring. Some extensions' descriptions may just exceed the calculated.
What's ur testing extension id?
These extensions have the problem on my machine.
! !
Maybe it's related to high-resolution screen. I'm sure it's an accidental problem, but it still exists. If you have the conditions, try adjusting the screen resolution scale to 150%.
there should be some bugs when doing sub pixel sampling whether it's related to windows DPI settings. can you reproduce this regularly without changing DPI?
Caused by can you please have a look at this?

maxHeight = Math.min(maxHeight, this._hover.containerDomNode.clientHeight); this._hover.containerDomNode.style.maxHeight = `${maxHeight}px`; <ins> if (this._hover.contentsDomNode.clientHeight > maxHeight) { this._hover.contentsDomNode.style.height = `${maxHeight}px`; } if (this._hover.contentsDomNode.clientHeight < this._hover.contentsDomNode.scrollHeight) { // Add padding for a vertical scrollbar const extraRightPadding = `${this._hover.scrollbar.options.verticalScrollbarSize}px`; if (this._hover.contentsDomNode.style.paddingRight !== extraRightPadding) { this._hover.contentsDomNode.style.paddingRight = extraRightPadding; } } </ins> } private setHoverPointerPosition(target: TargetRect): void {


Question:
Does this issue occur when all extensions are disabled?: No VS Code Version: 1.73.1 OS Version: Windows_NT x64 10.0. Steps to Reproduce: ! to the extension bar. to hover some items. Some one may not show the default scroll bar, but the problem is exists. ! I have tried to fix it. It seems caused by the visual bug from the issue . The scroll bar will show when the content is too long. This solution is great, but it causes another little bug in the screenshot. I think it's unwise to remove the tag, so I tried another way, just add to the tag : ! I'll make a PR after this issue has submitted.
I can't reproduce this srollbar for all extensions in the list: !
This bug is not 100% recurring. Some extensions' descriptions may just exceed the calculated.
What's ur testing extension id?
These extensions have the problem on my machine.
! !
Maybe it's related to high-resolution screen. I'm sure it's an accidental problem, but it still exists. If you have the conditions, try adjusting the screen resolution scale to 150%.
there should be some bugs when doing sub pixel sampling whether it's related to windows DPI settings. can you reproduce this regularly without changing DPI?
Caused by can you please have a look at this?

/* Must be higher than sash's z-index and terminal canvases */ z-index: 40; overflow: hidden; <del> overflow-y: auto; </del> max-width: 700px; }


Question:
Ref Right now I see: as a menu entry and command name "Get Started" as the tab name when looking at the welcome page "Show welcome page on startup" and "Reset welcome page walkthrough progress" "Getting Started with VS Code" as a walkthrough name There's a mix of "Welcome" and "Get Started" usage that makes it hard to differentiate between concepts. We could either revert back to "Welcome" for the welcome page itself or rename it to differentiate from the first walkthrough. Thoughts <img width="424" alt="CleanShot 2022-11-21 at 10 19 04 src="https://user-"<img width="200" alt="CleanShot 2022-11-21 at 10 19 12 src="https://user-"<img width="516" alt="CleanShot 2022-11-21 at 10 19 20 src="https://user-"<img width="273" alt="CleanShot 2022-11-21 at 10 19 23 src="https://user-"<img width="625" alt="CleanShot 2022-11-21 at 10 19 56 src="https://user-"
for historical context on naming here
Yeap..I believe changing the label in the tab to "Welcome" instead of "Get Started" is a good option - It should say Welcome on the tab here instead of Getting Started: ! When the user navigates away from the welcome page, the tab name should change to the walkthrough's name: It should say Learn the Fundamentals on the tab here instead of Getting Started: ! And this breadcrumb should say Welcome: !
"Welcome" was the old page and we "Get Started" as new name during development. "Get Started" did fit better for the walkthrough style, was a more action-style verb and used in many other apps. Not sure if more thoughts went into it, as the mockups that started in were before my time and already used "Get Started". I haven't many users ever get into Get Started or Welcome as command, so renaming would be low risk.
Is there a user issue mentioning the confusion? Asking to understand if we also need to account for user keyword search behavior in the command pallet when looking for walkthroughs or the Getting Started page after its been closed. Currently, most walkthroughs use the "Get Started" terminology - Searching for "Get..." in the command palette surfaces the walkthroughs. I wonder if search terms are influenced by the page on which users first saw the walkthroughs and will the naming change have implications on the keywords to find walkthroughs?
No specific issue that I know of, I'm just spotting the issue of the strange overloading myself. might know if we have any hard data on people searching for the command. But I'd also assume it's quite unlikely compared to going to the "Help" menu, for example.

constructor() { super({ id: 'workbench.action.openWalkthrough', <del> title: { value: localize('miGetStarted', "Get Started"), original: 'Get Started' }, </del> <ins> title: { value: localize('miWelcome', "Welcome"), original: 'Welcome' }, </ins> category: Categories.Help, f1: true, menu: {


Question:
Ref Right now I see: as a menu entry and command name "Get Started" as the tab name when looking at the welcome page "Show welcome page on startup" and "Reset welcome page walkthrough progress" "Getting Started with VS Code" as a walkthrough name There's a mix of "Welcome" and "Get Started" usage that makes it hard to differentiate between concepts. We could either revert back to "Welcome" for the welcome page itself or rename it to differentiate from the first walkthrough. Thoughts <img width="424" alt="CleanShot 2022-11-21 at 10 19 04 src="https://user-"<img width="200" alt="CleanShot 2022-11-21 at 10 19 12 src="https://user-"<img width="516" alt="CleanShot 2022-11-21 at 10 19 20 src="https://user-"<img width="273" alt="CleanShot 2022-11-21 at 10 19 23 src="https://user-"<img width="625" alt="CleanShot 2022-11-21 at 10 19 56 src="https://user-"
for historical context on naming here
Yeap..I believe changing the label in the tab to "Welcome" instead of "Get Started" is a good option - It should say Welcome on the tab here instead of Getting Started: ! When the user navigates away from the welcome page, the tab name should change to the walkthrough's name: It should say Learn the Fundamentals on the tab here instead of Getting Started: ! And this breadcrumb should say Welcome: !
"Welcome" was the old page and we "Get Started" as new name during development. "Get Started" did fit better for the walkthrough style, was a more action-style verb and used in many other apps. Not sure if more thoughts went into it, as the mockups that started in were before my time and already used "Get Started". I haven't many users ever get into Get Started or Welcome as command, so renaming would be low risk.
Is there a user issue mentioning the confusion? Asking to understand if we also need to account for user keyword search behavior in the command pallet when looking for walkthroughs or the Getting Started page after its been closed. Currently, most walkthroughs use the "Get Started" terminology - Searching for "Get..." in the command palette surfaces the walkthroughs. I wonder if search terms are influenced by the page on which users first saw the walkthroughs and will the naming change have implications on the keywords to find walkthroughs?
No specific issue that I know of, I'm just spotting the issue of the strange overloading myself. might know if we have any hard data on people searching for the command. But I'd also assume it's quite unlikely compared to going to the "Help" menu, for example.

EditorPaneDescriptor.create( GettingStartedPage, GettingStartedPage.ID, <del> localize('getStarted', "Get Started") </del> <ins> localize('welcome', "Welcome") </ins> ), [ new SyncDescriptor(GettingStartedInput) ] ); <del> const category = { value: localize('getStarted', "Get Started"), original: 'Get Started' }; </del> <ins> const category = { value: localize('welcome', "Welcome"), original: 'Welcome' }; </ins> registerAction2(class extends Action2 { constructor() {


Question:
Ref Right now I see: as a menu entry and command name "Get Started" as the tab name when looking at the welcome page "Show welcome page on startup" and "Reset welcome page walkthrough progress" "Getting Started with VS Code" as a walkthrough name There's a mix of "Welcome" and "Get Started" usage that makes it hard to differentiate between concepts. We could either revert back to "Welcome" for the welcome page itself or rename it to differentiate from the first walkthrough. Thoughts <img width="424" alt="CleanShot 2022-11-21 at 10 19 04 src="https://user-"<img width="200" alt="CleanShot 2022-11-21 at 10 19 12 src="https://user-"<img width="516" alt="CleanShot 2022-11-21 at 10 19 20 src="https://user-"<img width="273" alt="CleanShot 2022-11-21 at 10 19 23 src="https://user-"<img width="625" alt="CleanShot 2022-11-21 at 10 19 56 src="https://user-"
for historical context on naming here
Yeap..I believe changing the label in the tab to "Welcome" instead of "Get Started" is a good option - It should say Welcome on the tab here instead of Getting Started: ! When the user navigates away from the welcome page, the tab name should change to the walkthrough's name: It should say Learn the Fundamentals on the tab here instead of Getting Started: ! And this breadcrumb should say Welcome: !
"Welcome" was the old page and we "Get Started" as new name during development. "Get Started" did fit better for the walkthrough style, was a more action-style verb and used in many other apps. Not sure if more thoughts went into it, as the mockups that started in were before my time and already used "Get Started". I haven't many users ever get into Get Started or Welcome as command, so renaming would be low risk.
Is there a user issue mentioning the confusion? Asking to understand if we also need to account for user keyword search behavior in the command pallet when looking for walkthroughs or the Getting Started page after its been closed. Currently, most walkthroughs use the "Get Started" terminology - Searching for "Get..." in the command palette surfaces the walkthroughs. I wonder if search terms are influenced by the page on which users first saw the walkthroughs and will the naming change have implications on the keywords to find walkthroughs?
No specific issue that I know of, I'm just spotting the issue of the strange overloading myself. might know if we have any hard data on people searching for the command. But I'd also assume it's quite unlikely compared to going to the "Help" menu, for example.

this.categoriesSlide = $('.gettingStartedSlideCategories.gettingStartedSlide'); <del> const prevButton = $('button.prev-button.button-link', { 'x-dispatch': 'scrollPrev' }, $('span.scroll-button.codicon.codicon-chevron-left'), $('span.moreText', {}, localize('getStarted', "Get Started"))); </del> <ins> const prevButton = $('button.prev-button.button-link', { 'x-dispatch': 'scrollPrev' }, $('span.scroll-button.codicon.codicon-chevron-left'), $('span.moreText', {}, localize('welcome', "Welcome"))); </ins> this.stepsSlide = $('.gettingStartedSlideDetails.gettingStartedSlide', {}, prevButton); this.stepsContent = $('.gettingStartedDetailsContent', {});


Question:
Ref Right now I see: as a menu entry and command name "Get Started" as the tab name when looking at the welcome page "Show welcome page on startup" and "Reset welcome page walkthrough progress" "Getting Started with VS Code" as a walkthrough name There's a mix of "Welcome" and "Get Started" usage that makes it hard to differentiate between concepts. We could either revert back to "Welcome" for the welcome page itself or rename it to differentiate from the first walkthrough. Thoughts <img width="424" alt="CleanShot 2022-11-21 at 10 19 04 src="https://user-"<img width="200" alt="CleanShot 2022-11-21 at 10 19 12 src="https://user-"<img width="516" alt="CleanShot 2022-11-21 at 10 19 20 src="https://user-"<img width="273" alt="CleanShot 2022-11-21 at 10 19 23 src="https://user-"<img width="625" alt="CleanShot 2022-11-21 at 10 19 56 src="https://user-"
for historical context on naming here
Yeap..I believe changing the label in the tab to "Welcome" instead of "Get Started" is a good option - It should say Welcome on the tab here instead of Getting Started: ! When the user navigates away from the welcome page, the tab name should change to the walkthrough's name: It should say Learn the Fundamentals on the tab here instead of Getting Started: ! And this breadcrumb should say Welcome: !
"Welcome" was the old page and we "Get Started" as new name during development. "Get Started" did fit better for the walkthrough style, was a more action-style verb and used in many other apps. Not sure if more thoughts went into it, as the mockups that started in were before my time and already used "Get Started". I haven't many users ever get into Get Started or Welcome as command, so renaming would be low risk.
Is there a user issue mentioning the confusion? Asking to understand if we also need to account for user keyword search behavior in the command pallet when looking for walkthroughs or the Getting Started page after its been closed. Currently, most walkthroughs use the "Get Started" terminology - Searching for "Get..." in the command palette surfaces the walkthroughs. I wonder if search terms are influenced by the page on which users first saw the walkthroughs and will the naming change have implications on the keywords to find walkthroughs?
No specific issue that I know of, I'm just spotting the issue of the strange overloading myself. might know if we have any hard data on people searching for the command. But I'd also assume it's quite unlikely compared to going to the "Help" menu, for example.

// Seprate from main module to break dependency cycles between welcomePage and gettingStarted. export const welcomePageBackground = registerColor('welcomePage.background', { light: null, dark: null, hcDark: null, hcLight: null }, localize('welcomePage.background', 'Background color for the Welcome page.')); <del> export const welcomePageTileBackground = registerColor('welcomePage.tileBackground', { dark: editorWidgetBackground, light: editorWidgetBackground, hcDark: '#000', hcLight: editorWidgetBackground }, localize('welcomePage.tileBackground', 'Background color for the tiles on the Get Started page.')); export const welcomePageTileHoverBackground = registerColor('welcomePage.tileHoverBackground', { dark: lighten(editorWidgetBackground, .2), light: darken(editorWidgetBackground, .1), hcDark: null, hcLight: null }, localize('welcomePage.tileHoverBackground', 'Hover background color for the tiles on the Get Started.')); export const welcomePageTileBorder = registerColor('welcomePage.tileBorder', { dark: '#ffffff1a', light: '#0000001a', hcDark: contrastBorder, hcLight: contrastBorder }, localize('welcomePage.tileBorder', 'Border color for the tiles on the Get Started page.')); </del> <ins> export const welcomePageTileBackground = registerColor('welcomePage.tileBackground', { dark: editorWidgetBackground, light: editorWidgetBackground, hcDark: '#000', hcLight: editorWidgetBackground }, localize('welcomePage.tileBackground', 'Background color for the tiles on the Welcome page.')); export const welcomePageTileHoverBackground = registerColor('welcomePage.tileHoverBackground', { dark: lighten(editorWidgetBackground, .2), light: darken(editorWidgetBackground, .1), hcDark: null, hcLight: null }, localize('welcomePage.tileHoverBackground', 'Hover background color for the tiles on the Welcome.')); export const welcomePageTileBorder = registerColor('welcomePage.tileBorder', { dark: '#ffffff1a', light: '#0000001a', hcDark: contrastBorder, hcLight: contrastBorder }, localize('welcomePage.tileBorder', 'Border color for the tiles on the Welcome page.')); </ins> export const welcomePageProgressBackground = registerColor('welcomePage.progress.background', { light: inputBackground, dark: inputBackground, hcDark: inputBackground, hcLight: inputBackground }, localize('welcomePage.progress.background', 'Foreground color for the Welcome page progress bars.'));


Question:
Ref Right now I see: as a menu entry and command name "Get Started" as the tab name when looking at the welcome page "Show welcome page on startup" and "Reset welcome page walkthrough progress" "Getting Started with VS Code" as a walkthrough name There's a mix of "Welcome" and "Get Started" usage that makes it hard to differentiate between concepts. We could either revert back to "Welcome" for the welcome page itself or rename it to differentiate from the first walkthrough. Thoughts <img width="424" alt="CleanShot 2022-11-21 at 10 19 04 src="https://user-"<img width="200" alt="CleanShot 2022-11-21 at 10 19 12 src="https://user-"<img width="516" alt="CleanShot 2022-11-21 at 10 19 20 src="https://user-"<img width="273" alt="CleanShot 2022-11-21 at 10 19 23 src="https://user-"<img width="625" alt="CleanShot 2022-11-21 at 10 19 56 src="https://user-"
for historical context on naming here
Yeap..I believe changing the label in the tab to "Welcome" instead of "Get Started" is a good option - It should say Welcome on the tab here instead of Getting Started: ! When the user navigates away from the welcome page, the tab name should change to the walkthrough's name: It should say Learn the Fundamentals on the tab here instead of Getting Started: ! And this breadcrumb should say Welcome: !
"Welcome" was the old page and we "Get Started" as new name during development. "Get Started" did fit better for the walkthrough style, was a more action-style verb and used in many other apps. Not sure if more thoughts went into it, as the mockups that started in were before my time and already used "Get Started". I haven't many users ever get into Get Started or Welcome as command, so renaming would be low risk.
Is there a user issue mentioning the confusion? Asking to understand if we also need to account for user keyword search behavior in the command pallet when looking for walkthroughs or the Getting Started page after its been closed. Currently, most walkthroughs use the "Get Started" terminology - Searching for "Get..." in the command palette surfaces the walkthroughs. I wonder if search terms are influenced by the page on which users first saw the walkthroughs and will the naming change have implications on the keywords to find walkthroughs?
No specific issue that I know of, I'm just spotting the issue of the strange overloading myself. might know if we have any hard data on people searching for the command. But I'd also assume it's quite unlikely compared to going to the "Help" menu, for example.

} override getName() { <del> return localize('getStarted', "Get Started"); </del> <ins> return localize('getStarted', "Welcome"); </ins> } selectedCategory: string | undefined;


Question:
I suspect this comes from
You're right, this is: Right now, the module assumes that it will be called in the following order: It is possible that if a is skipped by the browser that we don't mark and that would cause an error at
Good morning I'm having trouble logging into the app. I get the following error. Uncaught SyntaxError: Failed to execute 'measure' on 'Performance': The mark '<REDACTED: user-file-path' does not exist. I hope you can help me with the solution. thank you.

* Mark the end of the keydown event. */ function markKeyDownEnd() { <del> performance.mark('keydown/end'); state.keydown = EventPhase.Finished; </del> <ins> if (state.keydown === EventPhase.InProgress) { performance.mark('keydown/end'); state.keydown = EventPhase.Finished; } </ins> } /**


Question:
I suspect this comes from
You're right, this is: Right now, the module assumes that it will be called in the following order: It is possible that if a is skipped by the browser that we don't mark and that would cause an error at
Good morning I'm having trouble logging into the app. I get the following error. Uncaught SyntaxError: Failed to execute 'measure' on 'Performance': The mark '<REDACTED: user-file-path' does not exist. I hope you can help me with the solution. thank you.

* Record the start of the input event. */ export function onInput() { <ins> if (state.input === EventPhase.Before) { // it looks like we didn't receive a `beforeinput` onBeforeInput(); } </ins> queueMicrotask(markInputEnd); } function markInputEnd() { <del> performance.mark('input/end'); state.input = EventPhase.Finished; </del> <ins> if (state.input === EventPhase.InProgress) { performance.mark('input/end'); state.input = EventPhase.Finished; } </ins> } /**


Question:
I suspect this comes from
You're right, this is: Right now, the module assumes that it will be called in the following order: It is possible that if a is skipped by the browser that we don't mark and that would cause an error at
Good morning I'm having trouble logging into the app. I get the following error. Uncaught SyntaxError: Failed to execute 'measure' on 'Performance': The mark '<REDACTED: user-file-path' does not exist. I hope you can help me with the solution. thank you.

* Mark the end of the animation frame performing the rendering. */ function markRenderEnd() { <del> performance.mark('render/end'); state.render = EventPhase.Finished; </del> <ins> if (state.render === EventPhase.InProgress) { performance.mark('render/end'); state.render = EventPhase.Finished; } </ins> } function scheduleRecordIfFinishedTask() {


Question:
I've seen this a lot over the past month and it seems like a major issue for notebooks, please consider investigating further for November ! ! ! ! While running integration tests today (23rd November): ! Version: 1.74.0-insider (user setup) Commit: Date: 2022-11-23T05:25:25.108Z Electron: 19.1.3 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
it's likely related to the position performance optimization this month.
Can you try debugging. I can never reproduce this The best place to start debugging is: Let me know if you want to pair on this later this afternoon too
Was finally able to repo this but not reliably. It seems to rely on a new being created, but this doesn't always happen. The most reliable repo for me: with a notebook and text editor in a single editor group the notebook editor down to create a new group below the text editor grab the notebook editor and drag it right to move the bottom editor to the right I think the root cause is that the notebook widget is passed the wrong position. I'm going to work around this by making the notebook editor ignore the position it is given, however this will also undo the performance fixes we made this iteration for notebook layout I don't fully understand the grid layout code but it seems that is being set incorrectly in cases where a new BranchNode/SplitView is created. Here's what I see happening after step 3 of the repo above: setter is called calls which creates a new the constructor, a new Split View is created is called on it. At this point, of the split view is: the time layout is called on the notebook editor widget, is computed as zero. This results in the wrong layout. Looking at the code, we can see that is passed in as the absolute offset in step 4: <img width="1104" alt="Screenshot 2022-11-30 at 12 48 54 PM" src="https://user-"If I then slightly resize the window, here's what happens: call on the split View for the new group now is: we layout the notebook editor, is now correctly computed as
Created new issue: , thanks for the steps

return this._scrollBeyondLastLine && !this.isEmbedded; } <del> layout(dimension: DOM.Dimension, shadowElement?: HTMLElement, position?: DOM.IDomPosition): void { </del> <ins> layout(dimension: DOM.Dimension, shadowElement?: HTMLElement, _position?: DOM.IDomPosition): void { </ins> if (!shadowElement && this._shadowElementViewInfo === null) { this._dimension = dimension; return;


Question:
I've seen this a lot over the past month and it seems like a major issue for notebooks, please consider investigating further for November ! ! ! ! While running integration tests today (23rd November): ! Version: 1.74.0-insider (user setup) Commit: Date: 2022-11-23T05:25:25.108Z Electron: 19.1.3 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
it's likely related to the position performance optimization this month.
Can you try debugging. I can never reproduce this The best place to start debugging is: Let me know if you want to pair on this later this afternoon too
Was finally able to repo this but not reliably. It seems to rely on a new being created, but this doesn't always happen. The most reliable repo for me: with a notebook and text editor in a single editor group the notebook editor down to create a new group below the text editor grab the notebook editor and drag it right to move the bottom editor to the right I think the root cause is that the notebook widget is passed the wrong position. I'm going to work around this by making the notebook editor ignore the position it is given, however this will also undo the performance fixes we made this iteration for notebook layout I don't fully understand the grid layout code but it seems that is being set incorrectly in cases where a new BranchNode/SplitView is created. Here's what I see happening after step 3 of the repo above: setter is called calls which creates a new the constructor, a new Split View is created is called on it. At this point, of the split view is: the time layout is called on the notebook editor widget, is computed as zero. This results in the wrong layout. Looking at the code, we can see that is passed in as the absolute offset in step 4: <img width="1104" alt="Screenshot 2022-11-30 at 12 48 54 PM" src="https://user-"If I then slightly resize the window, here's what happens: call on the split View for the new group now is: we layout the notebook editor, is now correctly computed as
Created new issue: , thanks for the steps

} if (shadowElement) { <del> this.updateShadowElement(shadowElement, dimension, position); </del> <ins> this.updateShadowElement(shadowElement, dimension, /*position*/ undefined); </ins> } if (this._shadowElementViewInfo && this._shadowElementViewInfo.width <= 0 && this._shadowElementViewInfo.height <= 0) {


Question:
I've seen this a lot over the past month and it seems like a major issue for notebooks, please consider investigating further for November ! ! ! ! While running integration tests today (23rd November): ! Version: 1.74.0-insider (user setup) Commit: Date: 2022-11-23T05:25:25.108Z Electron: 19.1.3 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
it's likely related to the position performance optimization this month.
Can you try debugging. I can never reproduce this The best place to start debugging is: Let me know if you want to pair on this later this afternoon too
Was finally able to repo this but not reliably. It seems to rely on a new being created, but this doesn't always happen. The most reliable repo for me: with a notebook and text editor in a single editor group the notebook editor down to create a new group below the text editor grab the notebook editor and drag it right to move the bottom editor to the right I think the root cause is that the notebook widget is passed the wrong position. I'm going to work around this by making the notebook editor ignore the position it is given, however this will also undo the performance fixes we made this iteration for notebook layout I don't fully understand the grid layout code but it seems that is being set incorrectly in cases where a new BranchNode/SplitView is created. Here's what I see happening after step 3 of the repo above: setter is called calls which creates a new the constructor, a new Split View is created is called on it. At this point, of the split view is: the time layout is called on the notebook editor widget, is computed as zero. This results in the wrong layout. Looking at the code, we can see that is passed in as the absolute offset in step 4: <img width="1104" alt="Screenshot 2022-11-30 at 12 48 54 PM" src="https://user-"If I then slightly resize the window, here's what happens: call on the split View for the new group now is: we layout the notebook editor, is now correctly computed as
Created new issue: , thanks for the steps

this._overlayContainer.style.position = 'absolute'; this._overlayContainer.style.overflow = 'hidden'; <del> this.layoutContainerOverShadowElement(dimension, position); </del> <ins> this.layoutContainerOverShadowElement(dimension, /*position*/ undefined); </ins> if (this._webviewTransparentCover) { this._webviewTransparentCover.style.height = `${dimension.height}px`;


Question:
Very often I loose the yellow markers in the editor for references, see here for example: ! Here I find references of  and quickly dismiss the results of the one file before clicking on the other. Both files were opened before.
Didn't reproduce for me. Please update with repro steps
steps be in a multi root workspace with and close all editors open click on  of (at the end of the file) run (I have it bound to command) expand by clicking it once in the references view click the first result remove the 2 references by clicking on the X starting from the first click on the last result from no more highlights in the editor at all Full video: !
When removing the -entry (all together or all by removing all its children) I am not (always) getting the selection change event.
anything special for reproing this? I haven't been able to hit it.
Selection change event should be fixed now.
Thanks
fyi noticing a few behavioural differences now, which maybe we tolerate but users might not: clicking on a file name now opens the first reference, previously I believe it was not navigating but just expanding/collapsing (see video 1) triggering find references seems to reveal a reference in another file in some cases (see video 2) ! !

this._disposables.push( vscode.commands.registerCommand('references-view.next', () => this.next(false)), vscode.commands.registerCommand('references-view.prev', () => this.previous(false)), <ins> _view.onDidChangeSelection(() => this._ensureSelectedElementIsVisible()), </ins> ); }


Question:
Very often I loose the yellow markers in the editor for references, see here for example: ! Here I find references of  and quickly dismiss the results of the one file before clicking on the other. Both files were opened before.
Didn't reproduce for me. Please update with repro steps
steps be in a multi root workspace with and close all editors open click on  of (at the end of the file) run (I have it bound to command) expand by clicking it once in the references view click the first result remove the 2 references by clicking on the X starting from the first click on the last result from no more highlights in the editor at all Full video: !
When removing the -entry (all together or all by removing all its children) I am not (always) getting the selection change event.
anything special for reproing this? I haven't been able to hit it.
Selection change event should be fixed now.
Thanks
fyi noticing a few behavioural differences now, which maybe we tolerate but users might not: clicking on a file name now opens the first reference, previously I believe it was not navigating but just expanding/collapsing (see video 1) triggering find references seems to reveal a reference in another file in some cases (see video 2) ! !

this._ctxCanNavigate.set(Boolean(this._delegate)); } <ins> private _ensureSelectedElementIsVisible(): void { if (this._view.selection.length === 0) { return; } const [item] = this._view.selection; const location = this._delegate?.location(item); if (!location) { return; } if (vscode.window.activeTextEditor?.document.uri.toString() !== location.uri.toString()) { this._open(location, true); } } </ins> private _anchor(): undefined | unknown { if (!this._delegate) { return undefined;


Question:
Very often I loose the yellow markers in the editor for references, see here for example: ! Here I find references of  and quickly dismiss the results of the one file before clicking on the other. Both files were opened before.
Didn't reproduce for me. Please update with repro steps
steps be in a multi root workspace with and close all editors open click on  of (at the end of the file) run (I have it bound to command) expand by clicking it once in the references view click the first result remove the 2 references by clicking on the X starting from the first click on the last result from no more highlights in the editor at all Full video: !
When removing the -entry (all together or all by removing all its children) I am not (always) getting the selection change event.
anything special for reproing this? I haven't been able to hit it.
Selection change event should be fixed now.
Thanks
fyi noticing a few behavioural differences now, which maybe we tolerate but users might not: clicking on a file name now opens the first reference, previously I believe it was not navigating but just expanding/collapsing (see video 1) triggering find references seems to reveal a reference in another file in some cases (see video 2) ! !

} location(item: FileItem | ReferenceItem) { <del> return item instanceof ReferenceItem ? item.location : undefined; </del> <ins> return item instanceof ReferenceItem ? item.location : new vscode.Location(item.uri, item.references[0]?.location.range ?? new vscode.Position(0, 0)); </ins> } nearest(uri: vscode.Uri, position: vscode.Position): FileItem | ReferenceItem | undefined {


Question:
A bug in our tracker for dirty models, somehow never reported but obvious in an issue I noticed with Copilot. The end result is that you see a dirty indicator e.g. in the explorer but no editor that is opening and associated with it. Steps:
Tried to look at the steps to repro but seems the link to the copilot issue is broken or at least I am not able to access it.
I'm still getting this with copilot nightly in insiders <img width="652" alt="image" src="https://user-"
Please note that my change does not fix the Copilot issue. The steps to verify are unclear: it is expected when you see an untitled editor opening. You must test with auto save on.
Setting back verified label based on the screenshot.

return false; // resource must not be pending to save } <del> if (this.filesConfigurationService.getAutoSaveMode() === AutoSaveMode.AFTER_SHORT_DELAY && !fileModel?.hasState(TextFileEditorModelState.ERROR)) { </del> <ins> if (resource.scheme !== Schemas.untitled && this.filesConfigurationService.getAutoSaveMode() === AutoSaveMode.AFTER_SHORT_DELAY && !fileModel?.hasState(TextFileEditorModelState.ERROR)) { </ins> // leave models auto saved after short delay unless <del> // the save resulted in an error </del> <ins> // the save resulted in an error and not for untitled // that are not auto-saved anyway </ins> return false; }


Question:
A bug in our tracker for dirty models, somehow never reported but obvious in an issue I noticed with Copilot. The end result is that you see a dirty indicator e.g. in the explorer but no editor that is opening and associated with it. Steps:
Tried to look at the steps to repro but seems the link to the copilot issue is broken or at least I am not able to access it.
I'm still getting this with copilot nightly in insiders <img width="652" alt="image" src="https://user-"
Please note that my change does not fix the Copilot issue. The steps to verify are unclear: it is expected when you see an untitled editor opening. You must test with auto save on.
Setting back verified label based on the screenshot.

} } <del> test('dirty untitled text file model opens as editor', async function () { const accessor = await createTracker(); </del> <ins> test('dirty untitled text file model opens as editor', function () { return testUntitledEditor(false); }); test('dirty untitled text file model opens as editor - autosave ON', function () { return testUntitledEditor(true); }); async function testUntitledEditor(autoSaveEnabled: boolean): Promise<void> { const accessor = await createTracker(autoSaveEnabled); </ins> const untitledTextEditor = await accessor.textEditorService.resolveTextEditor({ resource: undefined, forceUntitled: true }) as UntitledTextEditorInput; const model = disposables.add(await untitledTextEditor.resolve());


Question:
A bug in our tracker for dirty models, somehow never reported but obvious in an issue I noticed with Copilot. The end result is that you see a dirty indicator e.g. in the explorer but no editor that is opening and associated with it. Steps:
Tried to look at the steps to repro but seems the link to the copilot issue is broken or at least I am not able to access it.
I'm still getting this with copilot nightly in insiders <img width="652" alt="image" src="https://user-"
Please note that my change does not fix the Copilot issue. The steps to verify are unclear: it is expected when you see an untitled editor opening. You must test with auto save on.
Setting back verified label based on the screenshot.

await awaitEditorOpening(accessor.editorService); assert.ok(accessor.editorService.isOpened(untitledTextEditor)); <del> }); </del> <ins> } </ins> function awaitEditorOpening(editorService: IEditorService): Promise<void> { return Event.toPromise(Event.once(editorService.onDidActiveEditorChange));


Question:
Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-

@ILabelService private readonly _labelService: ILabelService ) { super(); <ins> for (const commandSelector of this._terminalContributionService.quickFixes) { this.registerCommandSelector(commandSelector); } </ins> const commandDetectionCapability = this._capabilities.get(TerminalCapability.CommandDetection); if (commandDetectionCapability) { this._registerCommandHandlers();


Question:
Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-

} }); } <del> for (const commandSelector of this._terminalContributionService.quickFixes) { this.registerCommandSelector(commandSelector); } </del> this._quickFixService.onDidRegisterProvider(result => this.registerCommandFinishedListener(convertToQuickFixOptions(result))); this._quickFixService.onDidUnregisterProvider(id => this._commandListeners.delete(id)); }


Question:
Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-

get providers(): Map<string, ITerminalQuickFixProvider> { return this._providers; } constructor(@ITerminalContributionService private readonly _terminalContributionService: ITerminalContributionService) { <del> for (const selector of this._terminalContributionService.quickFixes) { this.registerCommandSelector(selector); } </del> <ins> this._terminalContributionService.quickFixes.then(selectors => { for (const selector of selectors) { this.registerCommandSelector(selector); } }); </ins> } registerCommandSelector(selector: ITerminalCommandSelector): void {


Question:
Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-

})); } this._register(this._quickFixService.onDidRegisterProvider(result => this.registerCommandFinishedListener(convertToQuickFixOptions(result)))); <del> for (const selector of terminalContributionService.quickFixes) { this.registerCommandSelector(selector); } </del> <ins> terminalContributionService.quickFixes.then(quickFixSelectors => { for (const selector of quickFixSelectors) { this.registerCommandSelector(selector); } }); </ins> this._register(this._quickFixService.onDidRegisterCommandSelector(selector => this.registerCommandSelector(selector))); this._register(this._quickFixService.onDidUnregisterProvider(id => this._commandListeners.delete(id))); }


Question:
Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-

readonly _serviceBrand: undefined; readonly terminalProfiles: ReadonlyArray<IExtensionTerminalProfile>; <del> readonly quickFixes: Array<ITerminalCommandSelector>; </del> <ins> readonly quickFixes: Promise<Array<ITerminalCommandSelector>>; </ins> } export const ITerminalContributionService = createDecorator<ITerminalContributionService>('terminalContributionsService');


Question:
Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-

private _terminalProfiles: ReadonlyArray<IExtensionTerminalProfile> = []; get terminalProfiles() { return this._terminalProfiles; } <del> private _quickFixes: Array<ITerminalCommandSelector> = []; get quickFixes() { return this._quickFixes; } </del> <ins> quickFixes: Promise<Array<ITerminalCommandSelector>>; </ins> constructor() { <del> terminalsExtPoint.setHandler(contributions => { </del> <ins> this.quickFixes = new Promise((r) => terminalsExtPoint.setHandler(contributions => { </ins> this._terminalProfiles = contributions.map(c => { return c.value?.profiles?.filter(p => hasValidTerminalIcon(p)).map(e => { return { ...e, extensionIdentifier: c.description.identifier.value }; }) || []; }).flat(); <del> this._quickFixes = (contributions.filter(c => isProposedApiEnabled(c.description, 'terminalQuickFixProvider')).map(c => c.value.quickFixes ? c.value.quickFixes.map(fix => { return { ...fix, extensionIdentifier: c.description.identifier.value }; }) : [])).flat(); }); </del> <ins> const quickFixes = (contributions.filter(c => isProposedApiEnabled(c.description, 'terminalQuickFixProvider')).map(c => c.value.quickFixes ? c.value.quickFixes.map(fix => { return { ...fix, extensionIdentifier: c.description.identifier.value }; }) : [])).flat(); r(quickFixes); })); </ins> } }


Question:
Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-

rows: 30 }); instantiationService.stub(IStorageService, new TestStorageService()); <del> instantiationService.stub(ITerminalContributionService, { quickFixes: [] } as Partial<ITerminalContributionService>); </del> <ins> instantiationService.stub(ITerminalContributionService, { quickFixes: new Promise((r) => { r([]); }) } as Partial<ITerminalContributionService>); </ins> instantiationService.stub(ITerminalQuickFixService, { onDidRegisterProvider: new Emitter().event, onDidUnregisterProvider: new Emitter().event, onDidRegisterCommandSelector: new Emitter().event } as Partial<ITerminalQuickFixService>); instantiationService.stub(IConfigurationService, new TestConfigurationService()); instantiationService.stub(ILabelService, {} as Partial<ILabelService>);


Question:
Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-

class TestTerminalContributionService implements ITerminalContributionService { _serviceBrand: undefined; terminalProfiles: readonly IExtensionTerminalProfile[] = []; <del> quickFixes: ITerminalCommandSelector[] = []; </del> <ins> quickFixes: Promise<ITerminalCommandSelector[]> = new Promise((r) => { r([]); }); </ins> setProfiles(profiles: IExtensionTerminalProfile[]): void { this.terminalProfiles = profiles; }


Question:
Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-

import { ITerminalContributionService } from 'vs/workbench/contrib/terminal/common/terminalExtensionPoints'; export class TerminalQuickFixService implements ITerminalQuickFixService { <ins> declare _serviceBrand: undefined; private _selectors: Map<string, ITerminalCommandSelector> = new Map(); private _providers: Map<string, ITerminalQuickFixProvider> = new Map(); get providers(): Map<string, ITerminalQuickFixProvider> { return this._providers; } </ins> private readonly _onDidRegisterProvider = new Emitter<ITerminalQuickFixProviderSelector>(); readonly onDidRegisterProvider = this._onDidRegisterProvider.event; private readonly _onDidRegisterCommandSelector = new Emitter<ITerminalCommandSelector>(); readonly onDidRegisterCommandSelector = this._onDidRegisterCommandSelector.event; private readonly _onDidUnregisterProvider = new Emitter<string>(); readonly onDidUnregisterProvider = this._onDidUnregisterProvider.event; <del> _serviceBrand: undefined; _providers: Map<string, ITerminalQuickFixProvider> = new Map(); _selectors: Map<string, ITerminalCommandSelector> = new Map(); get providers(): Map<string, ITerminalQuickFixProvider> { return this._providers; } </del> constructor(@ITerminalContributionService private readonly _terminalContributionService: ITerminalContributionService) { this._terminalContributionService.quickFixes.then(selectors => {


Question:
Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-

} registerQuickFixProvider(id: string, provider: ITerminalQuickFixProvider): IDisposable { <del> this._providers.set(id, provider); const selector = this._selectors.get(id); if (!selector) { throw new Error(`No registered selector for ID: ${id}`); } this._onDidRegisterProvider.fire({ selector, provider }); </del> <ins> // This is more complicated than it looks like it should be because we need to return an // IDisposable synchronously but we must await ITerminalContributionService.quickFixes // asynchronously before actually registering the provider. let disposed = false; this._terminalContributionService.quickFixes.then(() => { if (disposed) { return; } this._providers.set(id, provider); const selector = this._selectors.get(id); if (!selector) { throw new Error(`No registered selector for ID: ${id}`); } this._onDidRegisterProvider.fire({ selector, provider }); }); </ins> return toDisposable(() => { <del> this._selectors.delete(id); </del> <ins> disposed = true; </ins> this._providers.delete(id); <del> this._onDidUnregisterProvider.fire(selector.id); </del> <ins> const selector = this._selectors.get(id); if (selector) { this._selectors.delete(id); this._onDidUnregisterProvider.fire(selector.id); } </ins> }); } }


Question:
Type: <bBug</bis enabled. Ensure is set to , or (any option that will restore the last open window after quiting and re-opening VSCode). a terminal in the editor area, e.g. using the command "Terminal: Create New Terminal in Editor Area". Type something into the terminal e.g. . VSCode via "Developer: Reload Window". Note that the terminal tab in the editor area is still there (restored) after the window is reloaded. This is the expected behavior. VSCode then reopen the application. Note that the terminal tab is not present (is not restored) when the window is restored (and since there is no terminal tab, there is also nowhere to restore the session to ) . This is unexpected behavior as previously this terminal tab would be restored into the editor area, with its session history, even after quitting and reopening VSCode. Another terminal persistence bug on 1.74.0, also related to killing terminals: VS Code version: Code 1.74.0 (, 2022-12-05T16:37:54.581Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-neovim0.0.94 calva2.0.321 file-browser0.2.11 portal0.35.0 viml0.1.7 prettier-vscode9.10.3 vscode-htmlhint1.0.4 vscode-sshfs1.25.0 ssh-config-syntax-highlighter0.0.4 sqltools0.26.0 sqltools-driver-pg0.4.0 errorlens3.6.0 learn-vim0.0.28 vspacecode0.10.10 whichkey0.11.3 markdown-all-in-one3.5.0 </details<!-- generated by issue reporter --
I cannot reproduce that in Insider's https://user-
have you typed in the terminal before reloading? if not, that's by design
Pardon me I was unclear in the original writeup. The problem occurs in step 4 and is now reflected in edits above. Thank you! Regarding the direct question: yes, I have typed in the terminal before reloading.
/duplicate
Reviving editor-area terminals was working great in 1.73.x. This was marked as a duplicate of a feature request. Is it not a regression?
Created a PR with a possible fix
VSCode v1.74.2 occurs the same problem, does the fix takes effect or I need to config some settings?
The fix will be available in 1.75 release or you can try it in insiders

readonly persistentProcessId: number | undefined; /** <del> * The id of a persistent process during the shutdown process */ shutdownPersistentProcessId: number | undefined; /** </del> * Whether the process should be persisted across reloads. */ readonly shouldPersist: boolean;


Question:
Type: <bBug</bis enabled. Ensure is set to , or (any option that will restore the last open window after quiting and re-opening VSCode). a terminal in the editor area, e.g. using the command "Terminal: Create New Terminal in Editor Area". Type something into the terminal e.g. . VSCode via "Developer: Reload Window". Note that the terminal tab in the editor area is still there (restored) after the window is reloaded. This is the expected behavior. VSCode then reopen the application. Note that the terminal tab is not present (is not restored) when the window is restored (and since there is no terminal tab, there is also nowhere to restore the session to ) . This is unexpected behavior as previously this terminal tab would be restored into the editor area, with its session history, even after quitting and reopening VSCode. Another terminal persistence bug on 1.74.0, also related to killing terminals: VS Code version: Code 1.74.0 (, 2022-12-05T16:37:54.581Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-neovim0.0.94 calva2.0.321 file-browser0.2.11 portal0.35.0 viml0.1.7 prettier-vscode9.10.3 vscode-htmlhint1.0.4 vscode-sshfs1.25.0 ssh-config-syntax-highlighter0.0.4 sqltools0.26.0 sqltools-driver-pg0.4.0 errorlens3.6.0 learn-vim0.0.28 vspacecode0.10.10 whichkey0.11.3 markdown-all-in-one3.5.0 </details<!-- generated by issue reporter --
I cannot reproduce that in Insider's https://user-
have you typed in the terminal before reloading? if not, that's by design
Pardon me I was unclear in the original writeup. The problem occurs in step 4 and is now reflected in edits above. Thank you! Regarding the direct question: yes, I have typed in the terminal before reloading.
/duplicate
Reviving editor-area terminals was working great in 1.73.x. This was marked as a duplicate of a feature request. Is it not a regression?
Created a PR with a possible fix
VSCode v1.74.2 occurs the same problem, does the fix takes effect or I need to config some settings?
The fix will be available in 1.75 release or you can try it in insiders

import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { IShellLaunchConfig, TerminalExitReason, TerminalLocation, TerminalSettingId } from 'vs/platform/terminal/common/terminal'; import { IEditorGroup } from 'vs/workbench/services/editor/common/editorGroupsService'; <del> import { ILifecycleService } from 'vs/workbench/services/lifecycle/common/lifecycle'; </del> <ins> import { ILifecycleService, ShutdownReason, WillShutdownEvent } from 'vs/workbench/services/lifecycle/common/lifecycle'; </ins> import { ConfirmOnKill } from 'vs/workbench/contrib/terminal/common/terminal'; import { IContextKey, IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; import { IConfigurationService } from 'vs/platform/configuration/common/configuration';


Question:
Type: <bBug</bis enabled. Ensure is set to , or (any option that will restore the last open window after quiting and re-opening VSCode). a terminal in the editor area, e.g. using the command "Terminal: Create New Terminal in Editor Area". Type something into the terminal e.g. . VSCode via "Developer: Reload Window". Note that the terminal tab in the editor area is still there (restored) after the window is reloaded. This is the expected behavior. VSCode then reopen the application. Note that the terminal tab is not present (is not restored) when the window is restored (and since there is no terminal tab, there is also nowhere to restore the session to ) . This is unexpected behavior as previously this terminal tab would be restored into the editor area, with its session history, even after quitting and reopening VSCode. Another terminal persistence bug on 1.74.0, also related to killing terminals: VS Code version: Code 1.74.0 (, 2022-12-05T16:37:54.581Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-neovim0.0.94 calva2.0.321 file-browser0.2.11 portal0.35.0 viml0.1.7 prettier-vscode9.10.3 vscode-htmlhint1.0.4 vscode-sshfs1.25.0 ssh-config-syntax-highlighter0.0.4 sqltools0.26.0 sqltools-driver-pg0.4.0 errorlens3.6.0 learn-vim0.0.28 vspacecode0.10.10 whichkey0.11.3 markdown-all-in-one3.5.0 </details<!-- generated by issue reporter --
I cannot reproduce that in Insider's https://user-
have you typed in the terminal before reloading? if not, that's by design
Pardon me I was unclear in the original writeup. The problem occurs in step 4 and is now reflected in edits above. Thank you! Regarding the direct question: yes, I have typed in the terminal before reloading.
/duplicate
Reviving editor-area terminals was working great in 1.73.x. This was marked as a duplicate of a feature request. Is it not a regression?
Created a PR with a possible fix
VSCode v1.74.2 occurs the same problem, does the fix takes effect or I need to config some settings?
The fix will be available in 1.75 release or you can try it in insiders

// Don't dispose editor when instance is torn down on shutdown to avoid extra work and so // the editor/tabs don't disappear <del> this._lifecycleService.onWillShutdown(() => { </del> <ins> this._lifecycleService.onWillShutdown((e: WillShutdownEvent) => { </ins> this._isShuttingDown = true; dispose(disposeListeners); <ins> // Don't touch processes if the shutdown was a result of reload as they will be reattached const shouldPersistTerminals = this._configurationService.getValue<boolean>(TerminalSettingId.EnablePersistentSessions) && e.reason === ShutdownReason.RELOAD; if (shouldPersistTerminals) { instance.detachProcessAndDispose(TerminalExitReason.Shutdown); } else { instance.dispose(TerminalExitReason.Shutdown); } </ins> }); }


Question:
Type: <bBug</bis enabled. Ensure is set to , or (any option that will restore the last open window after quiting and re-opening VSCode). a terminal in the editor area, e.g. using the command "Terminal: Create New Terminal in Editor Area". Type something into the terminal e.g. . VSCode via "Developer: Reload Window". Note that the terminal tab in the editor area is still there (restored) after the window is reloaded. This is the expected behavior. VSCode then reopen the application. Note that the terminal tab is not present (is not restored) when the window is restored (and since there is no terminal tab, there is also nowhere to restore the session to ) . This is unexpected behavior as previously this terminal tab would be restored into the editor area, with its session history, even after quitting and reopening VSCode. Another terminal persistence bug on 1.74.0, also related to killing terminals: VS Code version: Code 1.74.0 (, 2022-12-05T16:37:54.581Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-neovim0.0.94 calva2.0.321 file-browser0.2.11 portal0.35.0 viml0.1.7 prettier-vscode9.10.3 vscode-htmlhint1.0.4 vscode-sshfs1.25.0 ssh-config-syntax-highlighter0.0.4 sqltools0.26.0 sqltools-driver-pg0.4.0 errorlens3.6.0 learn-vim0.0.28 vspacecode0.10.10 whichkey0.11.3 markdown-all-in-one3.5.0 </details<!-- generated by issue reporter --
I cannot reproduce that in Insider's https://user-
have you typed in the terminal before reloading? if not, that's by design
Pardon me I was unclear in the original writeup. The problem occurs in step 4 and is now reflected in edits above. Thank you! Regarding the direct question: yes, I have typed in the terminal before reloading.
/duplicate
Reviving editor-area terminals was working great in 1.73.x. This was marked as a duplicate of a feature request. Is it not a regression?
Created a PR with a possible fix
VSCode v1.74.2 occurs the same problem, does the fix takes effect or I need to config some settings?
The fix will be available in 1.75 release or you can try it in insiders

readonly _processManager: ITerminalProcessManager; private readonly _resource: URI; <del> private _shutdownPersistentProcessId: number | undefined; </del> // Enables disposal of the xterm onKey // event when the CwdDetection capability // is added


Question:
Type: <bBug</bis enabled. Ensure is set to , or (any option that will restore the last open window after quiting and re-opening VSCode). a terminal in the editor area, e.g. using the command "Terminal: Create New Terminal in Editor Area". Type something into the terminal e.g. . VSCode via "Developer: Reload Window". Note that the terminal tab in the editor area is still there (restored) after the window is reloaded. This is the expected behavior. VSCode then reopen the application. Note that the terminal tab is not present (is not restored) when the window is restored (and since there is no terminal tab, there is also nowhere to restore the session to ) . This is unexpected behavior as previously this terminal tab would be restored into the editor area, with its session history, even after quitting and reopening VSCode. Another terminal persistence bug on 1.74.0, also related to killing terminals: VS Code version: Code 1.74.0 (, 2022-12-05T16:37:54.581Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-neovim0.0.94 calva2.0.321 file-browser0.2.11 portal0.35.0 viml0.1.7 prettier-vscode9.10.3 vscode-htmlhint1.0.4 vscode-sshfs1.25.0 ssh-config-syntax-highlighter0.0.4 sqltools0.26.0 sqltools-driver-pg0.4.0 errorlens3.6.0 learn-vim0.0.28 vspacecode0.10.10 whichkey0.11.3 markdown-all-in-one3.5.0 </details<!-- generated by issue reporter --
I cannot reproduce that in Insider's https://user-
have you typed in the terminal before reloading? if not, that's by design
Pardon me I was unclear in the original writeup. The problem occurs in step 4 and is now reflected in edits above. Thank you! Regarding the direct question: yes, I have typed in the terminal before reloading.
/duplicate
Reviving editor-area terminals was working great in 1.73.x. This was marked as a duplicate of a feature request. Is it not a regression?
Created a PR with a possible fix
VSCode v1.74.2 occurs the same problem, does the fix takes effect or I need to config some settings?
The fix will be available in 1.75 release or you can try it in insiders

return TerminalInstance._lastKnownCanvasDimensions; } <del> set shutdownPersistentProcessId(shutdownPersistentProcessId: number | undefined) { this._shutdownPersistentProcessId = shutdownPersistentProcessId; } get persistentProcessId(): number | undefined { return this._processManager.persistentProcessId ?? this._shutdownPersistentProcessId; } get shouldPersist(): boolean { return (this._processManager.shouldPersist || this._shutdownPersistentProcessId !== undefined) && !this.shellLaunchConfig.isTransient && (!this.reconnectionProperties || this._configurationService.getValue(TaskSettingId.Reconnection) === true); } </del> <ins> get persistentProcessId(): number | undefined { return this._processManager.persistentProcessId; } get shouldPersist(): boolean { return this._processManager.shouldPersist && !this.shellLaunchConfig.isTransient && (!this.reconnectionProperties || this._configurationService.getValue(TaskSettingId.Reconnection) === true); } </ins> /** * Create xterm.js instance and attach data listeners.


Question:
Type: <bBug</bis enabled. Ensure is set to , or (any option that will restore the last open window after quiting and re-opening VSCode). a terminal in the editor area, e.g. using the command "Terminal: Create New Terminal in Editor Area". Type something into the terminal e.g. . VSCode via "Developer: Reload Window". Note that the terminal tab in the editor area is still there (restored) after the window is reloaded. This is the expected behavior. VSCode then reopen the application. Note that the terminal tab is not present (is not restored) when the window is restored (and since there is no terminal tab, there is also nowhere to restore the session to ) . This is unexpected behavior as previously this terminal tab would be restored into the editor area, with its session history, even after quitting and reopening VSCode. Another terminal persistence bug on 1.74.0, also related to killing terminals: VS Code version: Code 1.74.0 (, 2022-12-05T16:37:54.581Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-neovim0.0.94 calva2.0.321 file-browser0.2.11 portal0.35.0 viml0.1.7 prettier-vscode9.10.3 vscode-htmlhint1.0.4 vscode-sshfs1.25.0 ssh-config-syntax-highlighter0.0.4 sqltools0.26.0 sqltools-driver-pg0.4.0 errorlens3.6.0 learn-vim0.0.28 vspacecode0.10.10 whichkey0.11.3 markdown-all-in-one3.5.0 </details<!-- generated by issue reporter --
I cannot reproduce that in Insider's https://user-
have you typed in the terminal before reloading? if not, that's by design
Pardon me I was unclear in the original writeup. The problem occurs in step 4 and is now reflected in edits above. Thank you! Regarding the direct question: yes, I have typed in the terminal before reloading.
/duplicate
Reviving editor-area terminals was working great in 1.73.x. This was marked as a duplicate of a feature request. Is it not a regression?
Created a PR with a possible fix
VSCode v1.74.2 occurs the same problem, does the fix takes effect or I need to config some settings?
The fix will be available in 1.75 release or you can try it in insiders

// Don't touch processes if the shutdown was a result of reload as they will be reattached const shouldPersistTerminals = this._configHelper.config.enablePersistentSessions && e.reason === ShutdownReason.RELOAD; if (shouldPersistTerminals) { <del> for (const instance of this.instances) { </del> <ins> for (const instance of this._terminalGroupService.instances) { </ins> instance.detachProcessAndDispose(TerminalExitReason.Shutdown); } return; } <del> // Force dispose of all terminal instances const shouldPersistTerminalsForEvent = this._shouldReviveProcesses(e.reason); for (const instance of this.instances) { if (shouldPersistTerminalsForEvent) { instance.shutdownPersistentProcessId = instance.persistentProcessId; } </del> <ins> // Force dispose of all pane terminal instances for (const instance of this._terminalGroupService.instances) { </ins> instance.dispose(TerminalExitReason.Shutdown); }


Question:
a change to the file and save, do not commit the diff view from the SCM view up and down in the notebook diff view :cheese: see cell metadata area skittering on screen (the recording below does not capture how frequently the skittering actually happens) https://user-
Just ran into this again: https://user-
I opened for that, I think we can actually just reopen this one
This issue should be gone now since we fixed the horizontal bar issue.

this._editorContainer.style.height = `${editorHeight}px`; this._register(this._editor.onDidContentSizeChange((e) => { <ins> if (this._editorLayoutInProgress) { return; } </ins> if (e.contentHeightChanged && this.cell.layoutInfo.editorHeight !== e.contentHeight) { this.cell.editorHeight = e.contentHeight; }


Question:
a change to the file and save, do not commit the diff view from the SCM view up and down in the notebook diff view :cheese: see cell metadata area skittering on screen (the recording below does not capture how frequently the skittering actually happens) https://user-
Just ran into this again: https://user-
I opened for that, I think we can actually just reopen this one
This issue should be gone now since we fixed the horizontal bar issue.

const editorViewState = this.cell.getSourceEditorViewState() as editorCommon.IDiffEditorViewState | null; if (editorViewState) { <del> console.log('restore view state', this.cell.modified.handle, editorViewState); </del> this._editor!.restoreViewState(editorViewState); }