Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.66.0 (x64) OS Version: 10.0. Build (Window 10) Steps to Reproduce: VS Code (or use the shortcut ) the first miliseconds after opening a new instance of VS Code, a "Window 7"-like window frame layout appears, before the usual VS Code look shows up (see the attached GIF). The GIF below first shows the expected behavior, opening version 1.65.0, followed by the current behavior of version 1.66.0. ! The two executables were downloaded from: and
Refs
that's the reason I went back to 1.65, frames are so annoying.
Hi just a small update: I've downloaded the latest VS Code Insiders and the problem now only appears when launching VS Code for the first time, but no longer when opening new windows from a running instance of it.
This issue persists in the new latest version release, .
The issue persists in today's release, .
Since the related bug in the Electron repo has a label, and today's VSCode uses , I believe we will be experiencing this bug for months.
The upstream Electron issue is at The issue was introduced in Electron v14.0.0-beta.5 and the commit that introduced the issue is The PR fixes the issue where frameless resizable windows show Windows 7 frames during startup, but there's a larger issue that is still unresolved even with that PR. I also searched through the thousands of to see whether they had anything to do with the issue, but I didn't find anything relevant even after reverting several suspicious commits. Running with Electron v14.0.0-beta.5 or newer on Windows 10 reproduces the issue. The PR fixes the issue for frameless resizable windows by calling at an earlier stage of program initialization. Assume the window is frameless and resizable. Then, the program sets to earlier in , and the following occurs: is not run, meaning is not removed from the style set in Line 62. This style parameter is passed in to a call at . is not run. Instead, the block above is run, which adds a style to the style passed into the call. , because of these styles being passed in, after the window is shown, we get a single message, and no messages after. NC in this case refers to non-client area, which is the frame. DWM stands for desktop windows manager. After adding a long of 30 seconds to the call above, I was able to use Spy++ to log messages to that window and see the following: I have also attached full logs to the end of this comment. For frameless windows that cannot resize, even if we call earlier, because the program would pass in , for the and calls above, the style would not be in the styles sent to the calls. As a result, what I see in Spy++ is being toggled three times, and several calls that result in messages being emitted. Using Spy++, I confirmed that the calls have the flag set. I have searched the Chromium and Electron codebases for and (as well as ) to see why the frame might be rendering more often when is not passed in. However, I haven't found anything within the codebase itself. Searching Windows documentation, I found the following: causes to be sent. Reference: However, I'm not sure whether this could explain the difference in behaviour between resizable and non-resizable windows. can pass in or to send to the window, which is why I searched for those two constants within the codebase. Reference: Also, Chromium handles by returning at , which I assume causes the message to occur. Also, Electron calls at . I noticed that if I don't call there, the Windows 7 frame doesn't show up, but then the Electron window doesn't render with the proper style (see ). I also noticed that when the Windows 7 frame shows up, it has the style of whatever was passed into that specific call. For example, if I add to the call, then for a second I see a Windows 7 frame with applied. I also tried creating a minimal project in VS to reproduce the issue but wasn't successful. The frame that rendered seemed to have a Windows 10 style rather than a Windows 7 one. I also tried registering a listener in for the messages, and it did seem to get hit, though I couldn't do anything with it. There's also the mysterious , but I wasn't able to apply it to resolve the issue.
The PR that linked above (partially based on ) should resolve the issue for VS Code Insiders and hence close this issue, but there's still more I'd like to investigate, especially for frameless non-resizable windows. I some lines to log the hwnd and style passed into each relevant and call. One example of the styles that show up: There's also another window being created really early, but I don't think it influences the issue. Good scenario (meaning no frame showing) with set to and staying Bad scenario with set to then Bad scenario with set to and staying The call with style causes the Windows 7 frame to render, and its style corresponds to is actually the same style just with , once again showing how mysterious the constant is. While working on , I also noticed that changing the order of the calls seemed to fix the issue for frameless non-resizable windows. In particular, on the Electron side, in , if I first called to pretend that the window is resizable, and then called (where ) after the call around line 365, then the issue is resolved even for frameless non-resizable windows. However, this workaround delays the call to hundreds of lines later, and I wouldn't be surprised if it would cause a regression elsewhere. Just like in the log file of the good case of the previous comment, only shows up once, rather than three times. For completeness, here are the logs with the styles for this scenario, excluding the logs: In this case, the style never comes up! I also tried delaying the call and calling instead of , but that doesn't work because it fails to pass to the call as well as the first call, both of which need for the frame not to render: can be used to change the non-client (NC) rendering policy and hence result in a call. However, I did not find any references to within the Electron and Chromium codebases that were actually called when running my minimal repro.
lets continue the investigation in
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified

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


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.66.0 (x64) OS Version: 10.0. Build (Window 10) Steps to Reproduce: VS Code (or use the shortcut ) the first miliseconds after opening a new instance of VS Code, a "Window 7"-like window frame layout appears, before the usual VS Code look shows up (see the attached GIF). The GIF below first shows the expected behavior, opening version 1.65.0, followed by the current behavior of version 1.66.0. ! The two executables were downloaded from: and
Refs
that's the reason I went back to 1.65, frames are so annoying.
Hi just a small update: I've downloaded the latest VS Code Insiders and the problem now only appears when launching VS Code for the first time, but no longer when opening new windows from a running instance of it.
This issue persists in the new latest version release, .
The issue persists in today's release, .
Since the related bug in the Electron repo has a label, and today's VSCode uses , I believe we will be experiencing this bug for months.
The upstream Electron issue is at The issue was introduced in Electron v14.0.0-beta.5 and the commit that introduced the issue is The PR fixes the issue where frameless resizable windows show Windows 7 frames during startup, but there's a larger issue that is still unresolved even with that PR. I also searched through the thousands of to see whether they had anything to do with the issue, but I didn't find anything relevant even after reverting several suspicious commits. Running with Electron v14.0.0-beta.5 or newer on Windows 10 reproduces the issue. The PR fixes the issue for frameless resizable windows by calling at an earlier stage of program initialization. Assume the window is frameless and resizable. Then, the program sets to earlier in , and the following occurs: is not run, meaning is not removed from the style set in Line 62. This style parameter is passed in to a call at . is not run. Instead, the block above is run, which adds a style to the style passed into the call. , because of these styles being passed in, after the window is shown, we get a single message, and no messages after. NC in this case refers to non-client area, which is the frame. DWM stands for desktop windows manager. After adding a long of 30 seconds to the call above, I was able to use Spy++ to log messages to that window and see the following: I have also attached full logs to the end of this comment. For frameless windows that cannot resize, even if we call earlier, because the program would pass in , for the and calls above, the style would not be in the styles sent to the calls. As a result, what I see in Spy++ is being toggled three times, and several calls that result in messages being emitted. Using Spy++, I confirmed that the calls have the flag set. I have searched the Chromium and Electron codebases for and (as well as ) to see why the frame might be rendering more often when is not passed in. However, I haven't found anything within the codebase itself. Searching Windows documentation, I found the following: causes to be sent. Reference: However, I'm not sure whether this could explain the difference in behaviour between resizable and non-resizable windows. can pass in or to send to the window, which is why I searched for those two constants within the codebase. Reference: Also, Chromium handles by returning at , which I assume causes the message to occur. Also, Electron calls at . I noticed that if I don't call there, the Windows 7 frame doesn't show up, but then the Electron window doesn't render with the proper style (see ). I also noticed that when the Windows 7 frame shows up, it has the style of whatever was passed into that specific call. For example, if I add to the call, then for a second I see a Windows 7 frame with applied. I also tried creating a minimal project in VS to reproduce the issue but wasn't successful. The frame that rendered seemed to have a Windows 10 style rather than a Windows 7 one. I also tried registering a listener in for the messages, and it did seem to get hit, though I couldn't do anything with it. There's also the mysterious , but I wasn't able to apply it to resolve the issue.
The PR that linked above (partially based on ) should resolve the issue for VS Code Insiders and hence close this issue, but there's still more I'd like to investigate, especially for frameless non-resizable windows. I some lines to log the hwnd and style passed into each relevant and call. One example of the styles that show up: There's also another window being created really early, but I don't think it influences the issue. Good scenario (meaning no frame showing) with set to and staying Bad scenario with set to then Bad scenario with set to and staying The call with style causes the Windows 7 frame to render, and its style corresponds to is actually the same style just with , once again showing how mysterious the constant is. While working on , I also noticed that changing the order of the calls seemed to fix the issue for frameless non-resizable windows. In particular, on the Electron side, in , if I first called to pretend that the window is resizable, and then called (where ) after the call around line 365, then the issue is resolved even for frameless non-resizable windows. However, this workaround delays the call to hundreds of lines later, and I wouldn't be surprised if it would cause a regression elsewhere. Just like in the log file of the good case of the previous comment, only shows up once, rather than three times. For completeness, here are the logs with the styles for this scenario, excluding the logs: In this case, the style never comes up! I also tried delaying the call and calling instead of , but that doesn't work because it fails to pass to the call as well as the first call, both of which need for the frame not to render: can be used to change the non-client (NC) rendering policy and hence result in a call. However, I did not find any references to within the Electron and Chromium codebases that were actually called when running my minimal repro.
lets continue the investigation in
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified

constructor(modulePath: string, args?: string[] | undefined, options?: UtilityProcessOptions); postMessage(channel: string, message: any, transfer?: Electron.MessagePortMain[]): void; kill(signal?: number | string): boolean; <del> on(event: 'exit', listener: (code: number | undefined) => void): this; </del> <ins> on(event: 'exit', listener: (event: Electron.Event, code: number) => void): this; </ins> on(event: 'spawn', listener: () => void): this; } }


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.66.0 (x64) OS Version: 10.0. Build (Window 10) Steps to Reproduce: VS Code (or use the shortcut ) the first miliseconds after opening a new instance of VS Code, a "Window 7"-like window frame layout appears, before the usual VS Code look shows up (see the attached GIF). The GIF below first shows the expected behavior, opening version 1.65.0, followed by the current behavior of version 1.66.0. ! The two executables were downloaded from: and
Refs
that's the reason I went back to 1.65, frames are so annoying.
Hi just a small update: I've downloaded the latest VS Code Insiders and the problem now only appears when launching VS Code for the first time, but no longer when opening new windows from a running instance of it.
This issue persists in the new latest version release, .
The issue persists in today's release, .
Since the related bug in the Electron repo has a label, and today's VSCode uses , I believe we will be experiencing this bug for months.
The upstream Electron issue is at The issue was introduced in Electron v14.0.0-beta.5 and the commit that introduced the issue is The PR fixes the issue where frameless resizable windows show Windows 7 frames during startup, but there's a larger issue that is still unresolved even with that PR. I also searched through the thousands of to see whether they had anything to do with the issue, but I didn't find anything relevant even after reverting several suspicious commits. Running with Electron v14.0.0-beta.5 or newer on Windows 10 reproduces the issue. The PR fixes the issue for frameless resizable windows by calling at an earlier stage of program initialization. Assume the window is frameless and resizable. Then, the program sets to earlier in , and the following occurs: is not run, meaning is not removed from the style set in Line 62. This style parameter is passed in to a call at . is not run. Instead, the block above is run, which adds a style to the style passed into the call. , because of these styles being passed in, after the window is shown, we get a single message, and no messages after. NC in this case refers to non-client area, which is the frame. DWM stands for desktop windows manager. After adding a long of 30 seconds to the call above, I was able to use Spy++ to log messages to that window and see the following: I have also attached full logs to the end of this comment. For frameless windows that cannot resize, even if we call earlier, because the program would pass in , for the and calls above, the style would not be in the styles sent to the calls. As a result, what I see in Spy++ is being toggled three times, and several calls that result in messages being emitted. Using Spy++, I confirmed that the calls have the flag set. I have searched the Chromium and Electron codebases for and (as well as ) to see why the frame might be rendering more often when is not passed in. However, I haven't found anything within the codebase itself. Searching Windows documentation, I found the following: causes to be sent. Reference: However, I'm not sure whether this could explain the difference in behaviour between resizable and non-resizable windows. can pass in or to send to the window, which is why I searched for those two constants within the codebase. Reference: Also, Chromium handles by returning at , which I assume causes the message to occur. Also, Electron calls at . I noticed that if I don't call there, the Windows 7 frame doesn't show up, but then the Electron window doesn't render with the proper style (see ). I also noticed that when the Windows 7 frame shows up, it has the style of whatever was passed into that specific call. For example, if I add to the call, then for a second I see a Windows 7 frame with applied. I also tried creating a minimal project in VS to reproduce the issue but wasn't successful. The frame that rendered seemed to have a Windows 10 style rather than a Windows 7 one. I also tried registering a listener in for the messages, and it did seem to get hit, though I couldn't do anything with it. There's also the mysterious , but I wasn't able to apply it to resolve the issue.
The PR that linked above (partially based on ) should resolve the issue for VS Code Insiders and hence close this issue, but there's still more I'd like to investigate, especially for frameless non-resizable windows. I some lines to log the hwnd and style passed into each relevant and call. One example of the styles that show up: There's also another window being created really early, but I don't think it influences the issue. Good scenario (meaning no frame showing) with set to and staying Bad scenario with set to then Bad scenario with set to and staying The call with style causes the Windows 7 frame to render, and its style corresponds to is actually the same style just with , once again showing how mysterious the constant is. While working on , I also noticed that changing the order of the calls seemed to fix the issue for frameless non-resizable windows. In particular, on the Electron side, in , if I first called to pretend that the window is resizable, and then called (where ) after the call around line 365, then the issue is resolved even for frameless non-resizable windows. However, this workaround delays the call to hundreds of lines later, and I wouldn't be surprised if it would cause a regression elsewhere. Just like in the log file of the good case of the previous comment, only shows up once, rather than three times. For completeness, here are the logs with the styles for this scenario, excluding the logs: In this case, the style never comes up! I also tried delaying the call and calling instead of , but that doesn't work because it fails to pass to the call as well as the first call, both of which need for the frame not to render: can be used to change the non-client (NC) rendering policy and hence result in a call. However, I did not find any references to within the Electron and Chromium codebases that were actually called when running my minimal repro.
lets continue the investigation in
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified

this._register(Event.fromNodeEventEmitter<void>(this._process, 'spawn')(() => { this._logService.info(`UtilityProcess<${this.id}>: received spawn event.`); })); <del> this._register(Event.fromNodeEventEmitter<number | undefined>(this._process, 'exit')((code: number | undefined) => { code = code || 0; </del> <ins> const onExit = Event.fromNodeEventEmitter<number>(this._process, 'exit', (_, code: number) => code); this._register(onExit((code: number) => { </ins> this._logService.info(`UtilityProcess<${this.id}>: received exit event with code ${code}.`); this._hasExited = true; this._onExit.fire({ pid: this._process!.pid!, code, signal: '' });


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.66.0 (x64) OS Version: 10.0. Build (Window 10) Steps to Reproduce: VS Code (or use the shortcut ) the first miliseconds after opening a new instance of VS Code, a "Window 7"-like window frame layout appears, before the usual VS Code look shows up (see the attached GIF). The GIF below first shows the expected behavior, opening version 1.65.0, followed by the current behavior of version 1.66.0. ! The two executables were downloaded from: and
Refs
that's the reason I went back to 1.65, frames are so annoying.
Hi just a small update: I've downloaded the latest VS Code Insiders and the problem now only appears when launching VS Code for the first time, but no longer when opening new windows from a running instance of it.
This issue persists in the new latest version release, .
The issue persists in today's release, .
Since the related bug in the Electron repo has a label, and today's VSCode uses , I believe we will be experiencing this bug for months.
The upstream Electron issue is at The issue was introduced in Electron v14.0.0-beta.5 and the commit that introduced the issue is The PR fixes the issue where frameless resizable windows show Windows 7 frames during startup, but there's a larger issue that is still unresolved even with that PR. I also searched through the thousands of to see whether they had anything to do with the issue, but I didn't find anything relevant even after reverting several suspicious commits. Running with Electron v14.0.0-beta.5 or newer on Windows 10 reproduces the issue. The PR fixes the issue for frameless resizable windows by calling at an earlier stage of program initialization. Assume the window is frameless and resizable. Then, the program sets to earlier in , and the following occurs: is not run, meaning is not removed from the style set in Line 62. This style parameter is passed in to a call at . is not run. Instead, the block above is run, which adds a style to the style passed into the call. , because of these styles being passed in, after the window is shown, we get a single message, and no messages after. NC in this case refers to non-client area, which is the frame. DWM stands for desktop windows manager. After adding a long of 30 seconds to the call above, I was able to use Spy++ to log messages to that window and see the following: I have also attached full logs to the end of this comment. For frameless windows that cannot resize, even if we call earlier, because the program would pass in , for the and calls above, the style would not be in the styles sent to the calls. As a result, what I see in Spy++ is being toggled three times, and several calls that result in messages being emitted. Using Spy++, I confirmed that the calls have the flag set. I have searched the Chromium and Electron codebases for and (as well as ) to see why the frame might be rendering more often when is not passed in. However, I haven't found anything within the codebase itself. Searching Windows documentation, I found the following: causes to be sent. Reference: However, I'm not sure whether this could explain the difference in behaviour between resizable and non-resizable windows. can pass in or to send to the window, which is why I searched for those two constants within the codebase. Reference: Also, Chromium handles by returning at , which I assume causes the message to occur. Also, Electron calls at . I noticed that if I don't call there, the Windows 7 frame doesn't show up, but then the Electron window doesn't render with the proper style (see ). I also noticed that when the Windows 7 frame shows up, it has the style of whatever was passed into that specific call. For example, if I add to the call, then for a second I see a Windows 7 frame with applied. I also tried creating a minimal project in VS to reproduce the issue but wasn't successful. The frame that rendered seemed to have a Windows 10 style rather than a Windows 7 one. I also tried registering a listener in for the messages, and it did seem to get hit, though I couldn't do anything with it. There's also the mysterious , but I wasn't able to apply it to resolve the issue.
The PR that linked above (partially based on ) should resolve the issue for VS Code Insiders and hence close this issue, but there's still more I'd like to investigate, especially for frameless non-resizable windows. I some lines to log the hwnd and style passed into each relevant and call. One example of the styles that show up: There's also another window being created really early, but I don't think it influences the issue. Good scenario (meaning no frame showing) with set to and staying Bad scenario with set to then Bad scenario with set to and staying The call with style causes the Windows 7 frame to render, and its style corresponds to is actually the same style just with , once again showing how mysterious the constant is. While working on , I also noticed that changing the order of the calls seemed to fix the issue for frameless non-resizable windows. In particular, on the Electron side, in , if I first called to pretend that the window is resizable, and then called (where ) after the call around line 365, then the issue is resolved even for frameless non-resizable windows. However, this workaround delays the call to hundreds of lines later, and I wouldn't be surprised if it would cause a regression elsewhere. Just like in the log file of the good case of the previous comment, only shows up once, rather than three times. For completeness, here are the logs with the styles for this scenario, excluding the logs: In this case, the style never comes up! I also tried delaying the call and calling instead of , but that doesn't work because it fails to pass to the call as well as the first call, both of which need for the frame not to render: can be used to change the non-client (NC) rendering policy and hence result in a call. However, I did not find any references to within the Electron and Chromium codebases that were actually called when running my minimal repro.
lets continue the investigation in
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified

resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"


Question: Issue Type: <bBug</bSteps to Reproduce:  in a Markdown cell in Jupyter notebook. The monospace font used in Jupyter notebook () Markdown code blocks is not consistent with in the settings. ! This does not occur in a seperate Markdown () file. ! VS Code version: Code 1.66.0 (, 2022-03-30T05:50:14.623Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --

code { font-size: 1em; <ins> font-family: var(--vscode-editor-font-family); </ins> } pre code { <del> font-family: var(--vscode-editor-font-family); </del> line-height: 1.357em; white-space: pre-wrap; }


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.66.0 OS: MacOS Monterey 12.3, Darwin x64 21.4.0 Steps to Reproduce: new new markdown cell, name it for instance or will only show and have deleted the 1) or 1. written manually
cc -- It looks like this is being sanitized out of md strings. A markdown cell containing will be sanitized to render as . If the cell contains it will render as expected, only removing the html tags. It seems to be happening at the following:

if (token.type === 'heading') { yield { depth: token.depth, <del> text: renderMarkdownAsPlaintext({ value: token.text }).trim() </del> <ins> text: renderMarkdownAsPlaintext({ value: token.raw }).trim() </ins> }; } }


Question:
<img width="776" alt="image" src="https://user-"I don't have stable reproduce, but this happens pretty often, especially I'm moving lines around.
I don't think this is a bug of injected text: When there are not decorations, there cannot be any injected text. This looks like there are some orphaned decorations.
Do you use the setting? Do you still see this with latest & greatest insiders?
I'm using the setting but haven't seen it for a while since I reported the issue.
Leaving this open, lets find steps
Is it possible that this is caused by the recursive issue?
Could be the case! The fix is to use it like this:
Oh, so inside the runner?
Yes, because change events are only send out after returns. Thus, is not reentrant anymore and will be assigned correctly.

} } } <del> const newDecorationIds = this._editor.deltaDecorations(decorationIdsToReplace, newDecorationsData.map(d => d.decoration)); for (let i = 0; i < newDecorationIds.length; i++) { const data = newDecorationsData[i]; this._decorationsMetadata.set(newDecorationIds[i], data); } </del> <ins> this._editor.changeDecorations(accessor => { const newDecorationIds = accessor.deltaDecorations(decorationIdsToReplace, newDecorationsData.map(d => d.decoration)); for (let i = 0; i < newDecorationIds.length; i++) { const data = newDecorationsData[i]; this._decorationsMetadata.set(newDecorationIds[i], data); } }); </ins> } private _fillInColors(props: CssProperties, hint: languages.InlayHint): void {


Question:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --In response to , I think this error should only be raised when a request actually fails. I have a network setup where my host operating system reports it doesn't have network connectivity, but it can actually reach the internet just fine through a configured proxy. I believe moving the online check to the would result in a more accurate error flow: Obligatory xkcd for my unique situation:
As mentioned by I expect shall provide right info whether VS Code can connect to internet or not. Is it possible to get this info from the error instead of ?

import { IRequestContext, IRequestOptions, OfflineError } from 'vs/base/parts/request/common/request'; export function request(options: IRequestOptions, token: CancellationToken): Promise<IRequestContext> { <del> if (!navigator.onLine) { throw new OfflineError(); } </del> if (options.proxyAuthorization) { options.headers = { ...(options.headers || {}),


Question:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --In response to , I think this error should only be raised when a request actually fails. I have a network setup where my host operating system reports it doesn't have network connectivity, but it can actually reach the internet just fine through a configured proxy. I believe moving the online check to the would result in a more accurate error flow: Obligatory xkcd for my unique situation:
As mentioned by I expect shall provide right info whether VS Code can connect to internet or not. Is it possible to get this info from the error instead of ?

setRequestHeaders(xhr, options); xhr.responseType = 'arraybuffer'; <del> xhr.onerror = e => reject(new Error(xhr.statusText && ('XHR failed: ' + xhr.statusText) || 'XHR failed')); </del> <ins> xhr.onerror = e => reject( navigator.onLine ? new Error(xhr.statusText && ('XHR failed: ' + xhr.statusText) || 'XHR failed') : new OfflineError() ); </ins> xhr.onload = (e) => { resolve({ res: {


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -

"vscode-proxy-agent": "^0.12.0", "vscode-regexpp": "^3.1.0", "vscode-textmate": "7.0.1", <del> "xterm": "4.19.0-beta.24", "xterm-addon-search": "0.9.0-beta.21", </del> <ins> "xterm": "4.19.0-beta.25", "xterm-addon-search": "0.9.0-beta.22", </ins> "xterm-addon-serialize": "0.7.0-beta.12", "xterm-addon-unicode11": "0.4.0-beta.3", <del> "xterm-addon-webgl": "0.12.0-beta.28", "xterm-headless": "4.19.0-beta.24", </del> <ins> "xterm-addon-webgl": "0.12.0-beta.29", "xterm-headless": "4.19.0-beta.25", </ins> "yauzl": "^2.9.2", "yazl": "^2.4.3" },


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -

"tas-client-umd": "0.1.4", "vscode-oniguruma": "1.6.1", "vscode-textmate": "7.0.1", <del> "xterm": "4.19.0-beta.24", "xterm-addon-search": "0.9.0-beta.21", </del> <ins> "xterm": "4.19.0-beta.25", "xterm-addon-search": "0.9.0-beta.22", </ins> "xterm-addon-unicode11": "0.4.0-beta.3", <del> "xterm-addon-webgl": "0.12.0-beta.28" </del> <ins> "xterm-addon-webgl": "0.12.0-beta.29" </ins> } }


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -

resolved "https://registry.yarnpkg.com/vscode-textmate/-/vscode-textmate-7.0.1.tgz#8118a32b02735dccd14f893b495fa5389ad7de79" integrity sha512-zQ5U/nuXAAMsh691FtV0wPz89nSkHbs+IQV8FDk+wew9BlSDhf4UmWGlWJfTR2Ti6xZv87Tj5fENzKf6Qk7aLw== <del> xterm-addon-search@0.9.0-beta.21: version "0.9.0-beta.21" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.21.tgz#5348fe25676cdd89ce3be52ae62a316b6f266176" integrity sha512-jh6kfRCpWRvZZkV9QghFYesSYHjybaLNEyYAD6uilZYfNHoGLa0zPgUkLOqoECL7K6rhBmSYOkKbc9MG4wNFMQ== </del> <ins> xterm-addon-search@0.9.0-beta.22: version "0.9.0-beta.22" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.22.tgz#18f2eabda82709cdd64dee003879b586869e28a3" integrity sha512-1I8W0bwjg6bUoNaESKHSkS9BN3Z9Xe44/zbUb6Un+pbb5Nun4LQvFwSLkAIdRrslxcbcHYIU/2Q7F1wCOWLbaA== </ins> xterm-addon-unicode11@0.4.0-beta.3: version "0.4.0-beta.3" resolved "https://registry.yarnpkg.com/xterm-addon-unicode11/-/xterm-addon-unicode11-0.4.0-beta.3.tgz#f350184155fafd5ad0d6fbf31d13e6ca7dea1efa" integrity sha512-FryZAVwbUjKTmwXnm1trch/2XO60F5JsDvOkZhzobV1hm10sFLVuZpFyHXiUx7TFeeFsvNP+S77LAtWoeT5z+Q== <del> xterm-addon-webgl@0.12.0-beta.28: version "0.12.0-beta.28" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.28.tgz#252f88fd15816c23789659a0e2545682cf1eec9c" integrity sha512-xpqZRYlyv+aNdDl46W2Hi2fxakNvdJDmWhOwGHPjOmex+kOYdBvVn4rRZmJ7xrKFuQVOfzb3SQCmpZ/njCpBJA== </del> <ins> xterm-addon-webgl@0.12.0-beta.29: version "0.12.0-beta.29" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.29.tgz#7a508595c4521d14d7ed4315a121f9e3f230a0f0" integrity sha512-NcZBsD0ar3ZpQX070hDIsyEBl/StRMNu6U+9crNpiD2rQVfkM1vcWkOv31Zlj3eu6/f8z5aStyZLRMCGFwiRbA== </ins> <del> xterm@4.19.0-beta.24: version "4.19.0-beta.24" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.24.tgz#12b62877d4cf133f4626db3a15f6ed267b3bbcb5" integrity sha512-GydvC2ExdsfjkiXhUVuZtDhc89IZfyMLFgw/nwWHrvkyq4iCVsHbMloEObV3lZmv+0oRpcGtTiorfzdWGiHG0A== </del> <ins> xterm@4.19.0-beta.25: version "4.19.0-beta.25" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.25.tgz#38f92d0fef1cfdb290ef8994449a04fa1a8c90a7" integrity sha512-pDiMWKN1Cj4+X/K9Xegp0SA0ZDEGVqiq7RPSy8oZO2wo2rze1BF20PAZb3/RSp30eY5WyOKilKnck4yNOsPzHw== </ins>


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -

resolved "https://registry.yarnpkg.com/wrappy/-/wrappy-1.0.2.tgz#b5243d8f3ec1aa35f1364605bc0d1036e30ab69f" integrity sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8= <del> xterm-addon-search@0.9.0-beta.21: version "0.9.0-beta.21" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.21.tgz#5348fe25676cdd89ce3be52ae62a316b6f266176" integrity sha512-jh6kfRCpWRvZZkV9QghFYesSYHjybaLNEyYAD6uilZYfNHoGLa0zPgUkLOqoECL7K6rhBmSYOkKbc9MG4wNFMQ== </del> <ins> xterm-addon-search@0.9.0-beta.22: version "0.9.0-beta.22" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.22.tgz#18f2eabda82709cdd64dee003879b586869e28a3" integrity sha512-1I8W0bwjg6bUoNaESKHSkS9BN3Z9Xe44/zbUb6Un+pbb5Nun4LQvFwSLkAIdRrslxcbcHYIU/2Q7F1wCOWLbaA== </ins> xterm-addon-serialize@0.7.0-beta.12: version "0.7.0-beta.12"


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -

resolved "https://registry.yarnpkg.com/xterm-addon-unicode11/-/xterm-addon-unicode11-0.4.0-beta.3.tgz#f350184155fafd5ad0d6fbf31d13e6ca7dea1efa" integrity sha512-FryZAVwbUjKTmwXnm1trch/2XO60F5JsDvOkZhzobV1hm10sFLVuZpFyHXiUx7TFeeFsvNP+S77LAtWoeT5z+Q== <del> xterm-addon-webgl@0.12.0-beta.28: version "0.12.0-beta.28" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.28.tgz#252f88fd15816c23789659a0e2545682cf1eec9c" integrity sha512-xpqZRYlyv+aNdDl46W2Hi2fxakNvdJDmWhOwGHPjOmex+kOYdBvVn4rRZmJ7xrKFuQVOfzb3SQCmpZ/njCpBJA== </del> <ins> xterm-addon-webgl@0.12.0-beta.29: version "0.12.0-beta.29" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.29.tgz#7a508595c4521d14d7ed4315a121f9e3f230a0f0" integrity sha512-NcZBsD0ar3ZpQX070hDIsyEBl/StRMNu6U+9crNpiD2rQVfkM1vcWkOv31Zlj3eu6/f8z5aStyZLRMCGFwiRbA== </ins> <del> xterm-headless@4.19.0-beta.24: version "4.19.0-beta.24" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-4.19.0-beta.24.tgz#17dab68ae1b2600b0926d4c47032599f3b2f24cc" integrity sha512-Coq8gQ9f5/kNr1yhpXTZqatTOHOYDF4XVp93SM12vRROH64bM0rUMec6ukuTAd8DD97UOWYUgR+n7+xD0iTTSg== </del> <ins> xterm-headless@4.19.0-beta.25: version "4.19.0-beta.25" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-4.19.0-beta.25.tgz#a0a1b59f386c44458f06b8ced64e3567371cc983" integrity sha512-UswSgymk3g9i6XTpFAasnqqIvWhi+AEWT+iO3kkjII6ll+dYEQgeZAv92EnCmeRHp11u5TP+IBAo8jy+aTYbtA== </ins> <del> xterm@4.19.0-beta.24: version "4.19.0-beta.24" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.24.tgz#12b62877d4cf133f4626db3a15f6ed267b3bbcb5" integrity sha512-GydvC2ExdsfjkiXhUVuZtDhc89IZfyMLFgw/nwWHrvkyq4iCVsHbMloEObV3lZmv+0oRpcGtTiorfzdWGiHG0A== </del> <ins> xterm@4.19.0-beta.25: version "4.19.0-beta.25" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.25.tgz#38f92d0fef1cfdb290ef8994449a04fa1a8c90a7" integrity sha512-pDiMWKN1Cj4+X/K9Xegp0SA0ZDEGVqiq7RPSy8oZO2wo2rze1BF20PAZb3/RSp30eY5WyOKilKnck4yNOsPzHw== </ins> yallist@^4.0.0: version "4.0.0"


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -

import { KeyCode } from 'vs/base/common/keyCodes'; import { FindReplaceState } from 'vs/editor/contrib/find/browser/findState'; import { IMessage as InputBoxMessage } from 'vs/base/browser/ui/inputbox/inputBox'; <del> import { SimpleButton, findPreviousMatchIcon, findNextMatchIcon } from 'vs/editor/contrib/find/browser/findWidget'; </del> <ins> import { SimpleButton, findPreviousMatchIcon, findNextMatchIcon, NLS_NO_RESULTS, NLS_MATCHES_LOCATION } from 'vs/editor/contrib/find/browser/findWidget'; </ins> import { IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; import { IContextViewService } from 'vs/platform/contextview/browser/contextView'; import { editorWidgetBackground, inputActiveOptionBorder, inputActiveOptionBackground, inputActiveOptionForeground, inputBackground, inputBorder, inputForeground, inputValidationErrorBackground, inputValidationErrorBorder, inputValidationErrorForeground, inputValidationInfoBackground, inputValidationInfoBorder, inputValidationInfoForeground, inputValidationWarningBackground, inputValidationWarningBorder, inputValidationWarningForeground, widgetShadow, editorWidgetForeground, errorForeground } from 'vs/platform/theme/common/colorRegistry'; import { IColorTheme, registerThemingParticipant } from 'vs/platform/theme/common/themeService'; import { ContextScopedFindInput } from 'vs/platform/history/browser/contextScopedHistoryWidget'; import { widgetClose } from 'vs/platform/theme/common/iconRegistry'; <ins> import * as strings from 'vs/base/common/strings'; </ins> const NLS_FIND_INPUT_LABEL = nls.localize('label.find', "Find"); const NLS_FIND_INPUT_" = nls.localize('placeholder.find', "Find");


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -

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


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -

dependencies: object-keys "~0.4.0" <del> xterm-addon-search@0.9.0-beta.21: version "0.9.0-beta.21" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.21.tgz#5348fe25676cdd89ce3be52ae62a316b6f266176" integrity sha512-jh6kfRCpWRvZZkV9QghFYesSYHjybaLNEyYAD6uilZYfNHoGLa0zPgUkLOqoECL7K6rhBmSYOkKbc9MG4wNFMQ== </del> <ins> xterm-addon-search@0.9.0-beta.22: version "0.9.0-beta.22" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.22.tgz#18f2eabda82709cdd64dee003879b586869e28a3" integrity sha512-1I8W0bwjg6bUoNaESKHSkS9BN3Z9Xe44/zbUb6Un+pbb5Nun4LQvFwSLkAIdRrslxcbcHYIU/2Q7F1wCOWLbaA== </ins> xterm-addon-serialize@0.7.0-beta.12: version "0.7.0-beta.12"


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -

resolved "https://registry.yarnpkg.com/xterm-addon-unicode11/-/xterm-addon-unicode11-0.4.0-beta.3.tgz#f350184155fafd5ad0d6fbf31d13e6ca7dea1efa" integrity sha512-FryZAVwbUjKTmwXnm1trch/2XO60F5JsDvOkZhzobV1hm10sFLVuZpFyHXiUx7TFeeFsvNP+S77LAtWoeT5z+Q== <del> xterm-addon-webgl@0.12.0-beta.28: version "0.12.0-beta.28" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.28.tgz#252f88fd15816c23789659a0e2545682cf1eec9c" integrity sha512-xpqZRYlyv+aNdDl46W2Hi2fxakNvdJDmWhOwGHPjOmex+kOYdBvVn4rRZmJ7xrKFuQVOfzb3SQCmpZ/njCpBJA== </del> <ins> xterm-addon-webgl@0.12.0-beta.29: version "0.12.0-beta.29" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.29.tgz#7a508595c4521d14d7ed4315a121f9e3f230a0f0" integrity sha512-NcZBsD0ar3ZpQX070hDIsyEBl/StRMNu6U+9crNpiD2rQVfkM1vcWkOv31Zlj3eu6/f8z5aStyZLRMCGFwiRbA== </ins> <del> xterm-headless@4.19.0-beta.24: version "4.19.0-beta.24" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-4.19.0-beta.24.tgz#17dab68ae1b2600b0926d4c47032599f3b2f24cc" integrity sha512-Coq8gQ9f5/kNr1yhpXTZqatTOHOYDF4XVp93SM12vRROH64bM0rUMec6ukuTAd8DD97UOWYUgR+n7+xD0iTTSg== </del> <ins> xterm-headless@4.19.0-beta.25: version "4.19.0-beta.25" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-4.19.0-beta.25.tgz#a0a1b59f386c44458f06b8ced64e3567371cc983" integrity sha512-UswSgymk3g9i6XTpFAasnqqIvWhi+AEWT+iO3kkjII6ll+dYEQgeZAv92EnCmeRHp11u5TP+IBAo8jy+aTYbtA== </ins> <del> xterm@4.19.0-beta.24: version "4.19.0-beta.24" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.24.tgz#12b62877d4cf133f4626db3a15f6ed267b3bbcb5" integrity sha512-GydvC2ExdsfjkiXhUVuZtDhc89IZfyMLFgw/nwWHrvkyq4iCVsHbMloEObV3lZmv+0oRpcGtTiorfzdWGiHG0A== </del> <ins> xterm@4.19.0-beta.25: version "4.19.0-beta.25" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.25.tgz#38f92d0fef1cfdb290ef8994449a04fa1a8c90a7" integrity sha512-pDiMWKN1Cj4+X/K9Xegp0SA0ZDEGVqiq7RPSy8oZO2wo2rze1BF20PAZb3/RSp30eY5WyOKilKnck4yNOsPzHw== </ins> y18n@^3.2.1: version "3.2.2"


Question: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.66.2 (Universal) Commit: Date: 2022-04-11T07:49:20.994Z Electron: 17.2.0 Chromium: 98.0.4758.109 16.13.0 V8: 9.8.177.11-electron.0 OS: Darwin x64 20.5.0 Steps to Reproduce: push a commit to a repo that user don't have permission message modal will show to ask user if they want to create a fork repo button create a fork for you user don't want to creat a fork, that's why they close it. <img width="504" alt="Screen Shot 2022-04-29 at 11 18 18 PM" src="https://user-"I check the code, looks like github extention only check  to return. What I suggest If you think this were resonable, I will make a PR for it

const no = localize('no', "No"); const answer = await window.showInformationMessage(localize('fork', "You don't have permissions to push to '{0}/{1}' on GitHub. Would you like to create a fork and push to it instead?", owner, repo), yes, no); <del> if (answer === no) { </del> <ins> if (answer !== yes) { </ins> return; }


Question:
Issue Type: <bBug</bI had a file with unusual line endings in it, and this happened: the dialog kept reappearing after pressing 'ignore' until i finally relented. When I tried to create a new file with weird line endings it seemed to work, maybe since I had the file opened while the file was being generated, every time the file changed the dialog was re-enqueued even though it was already open? VS Code version: Code 1.66.2 (Universal) (, 2022-04-11T07:49:20.994Z) OS version: Darwin arm64 21.1.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ astro-vscode0.16.0 vscode-graphql0.4.4 vscode-docker1.22.0 svelte-vscode105.16.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
could you post some steps to verify?
I could not reproduce this myself, I did the change by realizing that the code showing the dialog is re-entrant. Could you please verify the fix using our
<!-- 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!
I tried adding to the end of files and got the dialog, but I couldn't get the dialog to keep showing up on Stable.
Verified by code review
unfortunately it was a one-off conversion script from an old system that caused the issue which I don't have any longer, so I'm not sure about the exact steps to reproduce it! edit: oops wrong account, i'm threecreepio. :D

import { IEditorContribution } from 'vs/editor/common/editorCommon'; import { ITextModel } from 'vs/editor/common/model'; import * as nls from 'vs/nls'; <del> import { IDialogService } from 'vs/platform/dialogs/common/dialogs'; </del> <ins> import { IConfirmationResult, IDialogService } from 'vs/platform/dialogs/common/dialogs'; </ins> const ignoreUnusualLineTerminators = 'ignoreUnusualLineTerminators';


Question:
Issue Type: <bBug</bI had a file with unusual line endings in it, and this happened: the dialog kept reappearing after pressing 'ignore' until i finally relented. When I tried to create a new file with weird line endings it seemed to work, maybe since I had the file opened while the file was being generated, every time the file changed the dialog was re-enqueued even though it was already open? VS Code version: Code 1.66.2 (Universal) (, 2022-04-11T07:49:20.994Z) OS version: Darwin arm64 21.1.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ astro-vscode0.16.0 vscode-graphql0.4.4 vscode-docker1.22.0 svelte-vscode105.16.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
could you post some steps to verify?
I could not reproduce this myself, I did the change by realizing that the code showing the dialog is re-entrant. Could you please verify the fix using our
<!-- 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!
I tried adding to the end of files and got the dialog, but I couldn't get the dialog to keep showing up on Stable.
Verified by code review
unfortunately it was a one-off conversion script from an old system that caused the issue which I don't have any longer, so I'm not sure about the exact steps to reproduce it! edit: oops wrong account, i'm threecreepio. :D

public static readonly ID = 'editor.contrib.unusualLineTerminatorsDetector'; private _config: 'auto' | 'off' | 'prompt'; <ins> private _isPresentingDialog: boolean = false; </ins> constructor( private readonly _editor: ICodeEditor,


Question:
Issue Type: <bBug</bI had a file with unusual line endings in it, and this happened: the dialog kept reappearing after pressing 'ignore' until i finally relented. When I tried to create a new file with weird line endings it seemed to work, maybe since I had the file opened while the file was being generated, every time the file changed the dialog was re-enqueued even though it was already open? VS Code version: Code 1.66.2 (Universal) (, 2022-04-11T07:49:20.994Z) OS version: Darwin arm64 21.1.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ astro-vscode0.16.0 vscode-graphql0.4.4 vscode-docker1.22.0 svelte-vscode105.16.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
could you post some steps to verify?
I could not reproduce this myself, I did the change by realizing that the code showing the dialog is re-entrant. Could you please verify the fix using our
<!-- 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!
I tried adding to the end of files and got the dialog, but I couldn't get the dialog to keep showing up on Stable.
Verified by code review
unfortunately it was a one-off conversion script from an old system that caused the issue which I don't have any longer, so I'm not sure about the exact steps to reproduce it! edit: oops wrong account, i'm threecreepio. :D

return; } <del> const result = await this._dialogService.confirm({ title: nls.localize('unusualLineTerminators.title', "Unusual Line Terminators"), message: nls.localize('unusualLineTerminators.message', "Detected unusual line terminators"), detail: nls.localize('unusualLineTerminators.detail', "The file '{0}' contains one or more unusual line terminator characters, like Line Separator (LS) or Paragraph Separator (PS).nnIt is recommended to remove them from the file. This can be configured via `editor.unusualLineTerminators`.", basename(model.uri)), primaryButton: nls.localize('unusualLineTerminators.fix', "Remove Unusual Line Terminators"), secondaryButton: nls.localize('unusualLineTerminators.ignore', "Ignore") }); </del> <ins> if (this._isPresentingDialog) { // we're currently showing the dialog, which is async. // avoid spamming the user return; } let result: IConfirmationResult; try { this._isPresentingDialog = true; result = await this._dialogService.confirm({ title: nls.localize('unusualLineTerminators.title', "Unusual Line Terminators"), message: nls.localize('unusualLineTerminators.message', "Detected unusual line terminators"), detail: nls.localize('unusualLineTerminators.detail', "The file '{0}' contains one or more unusual line terminator characters, like Line Separator (LS) or Paragraph Separator (PS).nnIt is recommended to remove them from the file. This can be configured via `editor.unusualLineTerminators`.", basename(model.uri)), primaryButton: nls.localize('unusualLineTerminators.fix', "Remove Unusual Line Terminators"), secondaryButton: nls.localize('unusualLineTerminators.ignore', "Ignore") }); } finally { this._isPresentingDialog = false; } </ins> if (!result.confirmed) { // this model should be ignored


Question:
Issue Type: <bBug</bWhen closing the Python interactive window the Terminal panel shows itself. ! VS Code version: Code 1.67.0 (, 2022-05-04T12:06:02.889Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <details<summaryExtensions (8)</summaryExtensionVersion ------ remotehub0.32.0 python2022.6.0 vscode-pylance2022.4.3 jupyter2022.4. jupyter-keymap1.0.0 jupyter-renderers1.0.6 remote-repositories0.6.0 markdown-all-in-one3.4.3 </details<!-- generated by issue reporter --
what's the recommended approach to debug this? I'm not sure who is opening the terminal (but I know it's not notebook or iw as it's the editor tab close button)
I debugged this, and determined that when the interactive window is closed, it updates a context key which hide a view container in the panel. this incorrectly triggers the panel to show.

contextKey.set(true); this.compositeBar.addComposite({ id: viewContainer.id, name: viewContainer.title, order: viewContainer.order, requestedIndex: viewContainer.requestedIndex }); <del> const activeComposite = this.getActiveComposite(); if (activeComposite === undefined || activeComposite.getId() === viewContainer.id) { this.compositeBar.activateComposite(viewContainer.id); </del> <ins> if (this.layoutService.isVisible(this.partId)) { const activeComposite = this.getActiveComposite(); if (activeComposite === undefined || activeComposite.getId() === viewContainer.id) { this.compositeBar.activateComposite(viewContainer.id); } </ins> } this.layoutCompositeBar();


Question: Open in two different tabs Make sure settings sync is OFF Change the theme in one tab Theme is not updated in other tab

// User data let userDataProvider; if (indexedDB) { <del> userDataProvider = new IndexedDBFileSystemProvider(logsPath.scheme, indexedDB, userDataStore, false); </del> <ins> userDataProvider = new IndexedDBFileSystemProvider(Schemas.vscodeUserData, indexedDB, userDataStore, true); </ins> this.registerDeveloperActions(<IndexedDBFileSystemProvider>userDataProvider); } else { logService.info('Using in-memory user data provider');


Question:
The layout controls icons can be a bit of an eye sore when in the default state. One way to remedy this and to give a stronger indication of the state, we could swap icons based on their state. Would look something like this: https://user-
these icon are now in: - -

public static readonly layoutStatusbar = new Codicon('layout-statusbar', { fontCharacter: 'ebf5' }); public static readonly layoutMenubar = new Codicon('layout-menubar', { fontCharacter: 'ebf6' }); public static readonly layoutCentered = new Codicon('layout-centered', { fontCharacter: 'ebf7' }); <ins> public static readonly layoutSidebarRightOff = new Codicon('layout-sidebar-right-off', { fontCharacter: 'ec00' }); public static readonly layoutPanelOff = new Codicon('layout-panel-off', { fontCharacter: 'ec01' }); public static readonly layoutSidebarLeftOff = new Codicon('layout-sidebar-left-off', { fontCharacter: 'ec02' }); </ins> public static readonly target = new Codicon('target', { fontCharacter: 'ebf8' }); public static readonly indent = new Codicon('indent', { fontCharacter: 'ebf9' }); public static readonly recordSmall = new Codicon('record-small', { fontCharacter: 'ebfa' });


Question:
Many of these onDispose listeners get created:
we fixed this at one pt. !
They were in and
here's when we lost it
want to fix it since you're working on that PR?
Let's hold off until it's done, this PR is complicated enough without merge problems
it's a simple fix - literally adding to the conditional on line 218
Did another review and haven't seen this issue since

if (beforeCommandExecution && !this._placeholderDecoration) { this._placeholderDecoration = decoration; this._placeholderDecoration.onDispose(() => this._placeholderDecoration = undefined); <del> } else { </del> <ins> } else if (!this._decorations.get(decoration.marker.id)) { </ins> decoration.onDispose(() => this._decorations.delete(decoration.marker.id)); this._decorations.set(decoration.marker.id, {


Question:
Our presubmit tests started to fail consistently since our test setup picked up code 1.67.0 yesterday. Our test is basically doing first, run written with from after the extension tests succeed, run a check on the consistency between our file and documentation/settings info. After running the extension tests with 1.67.0, it looks like the second step that involves reading sees a differently formatted Actually, it's not only a differently formatted , but it includes a new property (, , ...) at the end. The test passes if I make the extension tests to use 1.66.2. We can work around by arranging our presubmit test order or rewriting our test logic to handle this. But, we want to understand what is going on behind the scene and why this modification is necessary. Thanks!
this looks suspicious...
This is designed and expected. It is the metadata VS Code stores per extension while installing that can be used later for other features like updating etc., So I would recommend your extension to handle this.
this has started breaking our extension's tests without warning, and moreover, the way it writes to it's modifying the whole file (looks like whitespace changes).
how have you gone about working around this breaking change? I'm trying to get a release out myself and am suddenly blocked
Whelp, something else went on that broke my tests, but definitely noticed this too and will need to be careful about not committing the reformatted .
Sorry about the caused breakage. I am not sure what is your test doing, but I think it's not a good idea to depend on the content of , because VS Code uses it to write metadata about the extension. We do not remove any existing data but add more data.
What's the recommended way of dealing with the property when testing an extension with set to a version-controlled source directory? Should the changes be committed or do extension authors have to take care of reverting it (which probably means parsing and clearing the property).
I'm currently reverting it. Would love to know if we should do otherwise.
Reopening this to investigate if there is something changed on VS Code while running extension tests
I wanted to re-report this issue, because it was previously misunderstood and closed. Of course I won’t now this is open, but I already typed out reproduction steps. Perhaps they help. Steps to Reproduce: a git repository (this makes the issue more clear) a minimal VSCode extension with a test. The issue becomes more apparent if an existing extension name / publisher is used. .gitignore and commit we actually reproduce the bug. Run the extension tests Note that running tests has modified . Formatting is changed to use tabs, the final newline is stripped, and publisher metadata is to the file.
To verify: Create some hello world extension and open it's and change the and properties to an extension that already exists in Marketplace. Eg:Quit Code Insiders and Start from CLI with following arguments Make sure hello world extension's is not updated with property
This looks related to which didn't have anything to do with testing the extension, but only debugging it, and getting the same metadata written to an "unsuspecting" Will this fix handle this SO situation as well? The problem occurred very rarely so I couldn't give steps to reproduce, but I was only debugging and not running tests on the extension.
Yes
I have learned more about my situation of getting this extra data when debugging an extension. It happens when the extension writes to the . I have a couple of extensions which allow the user to make settings that will be read and converted to commands. I files a separate issue:

getTargetPlatform(): Promise<TargetPlatform>; <del> scanAllExtensions(systemScanOptions: ScanOptions, userScanOptions: ScanOptions): Promise<IScannedExtension[]>; </del> <ins> scanAllExtensions(systemScanOptions: ScanOptions, userScanOptions: ScanOptions, includeExtensionsUnderDev: boolean): Promise<IScannedExtension[]>; </ins> scanSystemExtensions(scanOptions: ScanOptions): Promise<IScannedExtension[]>; scanUserExtensions(scanOptions: ScanOptions): Promise<IScannedExtension[]>; scanExtensionsUnderDevelopment(scanOptions: ScanOptions, existingExtensions: IScannedExtension[]): Promise<IScannedExtension[]>;


Question:
Our presubmit tests started to fail consistently since our test setup picked up code 1.67.0 yesterday. Our test is basically doing first, run written with from after the extension tests succeed, run a check on the consistency between our file and documentation/settings info. After running the extension tests with 1.67.0, it looks like the second step that involves reading sees a differently formatted Actually, it's not only a differently formatted , but it includes a new property (, , ...) at the end. The test passes if I make the extension tests to use 1.66.2. We can work around by arranging our presubmit test order or rewriting our test logic to handle this. But, we want to understand what is going on behind the scene and why this modification is necessary. Thanks!
this looks suspicious...
This is designed and expected. It is the metadata VS Code stores per extension while installing that can be used later for other features like updating etc., So I would recommend your extension to handle this.
this has started breaking our extension's tests without warning, and moreover, the way it writes to it's modifying the whole file (looks like whitespace changes).
how have you gone about working around this breaking change? I'm trying to get a release out myself and am suddenly blocked
Whelp, something else went on that broke my tests, but definitely noticed this too and will need to be careful about not committing the reformatted .
Sorry about the caused breakage. I am not sure what is your test doing, but I think it's not a good idea to depend on the content of , because VS Code uses it to write metadata about the extension. We do not remove any existing data but add more data.
What's the recommended way of dealing with the property when testing an extension with set to a version-controlled source directory? Should the changes be committed or do extension authors have to take care of reverting it (which probably means parsing and clearing the property).
I'm currently reverting it. Would love to know if we should do otherwise.
Reopening this to investigate if there is something changed on VS Code while running extension tests
I wanted to re-report this issue, because it was previously misunderstood and closed. Of course I won’t now this is open, but I already typed out reproduction steps. Perhaps they help. Steps to Reproduce: a git repository (this makes the issue more clear) a minimal VSCode extension with a test. The issue becomes more apparent if an existing extension name / publisher is used. .gitignore and commit we actually reproduce the bug. Run the extension tests Note that running tests has modified . Formatting is changed to use tabs, the final newline is stripped, and publisher metadata is to the file.
To verify: Create some hello world extension and open it's and change the and properties to an extension that already exists in Marketplace. Eg:Quit Code Insiders and Start from CLI with following arguments Make sure hello world extension's is not updated with property
This looks related to which didn't have anything to do with testing the extension, but only debugging it, and getting the same metadata written to an "unsuspecting" Will this fix handle this SO situation as well? The problem occurred very rarely so I couldn't give steps to reproduce, but I was only debugging and not running tests on the extension.
Yes
I have learned more about my situation of getting this extra data when debugging an extension. It happens when the extension writes to the . I have a couple of extensions which allow the user to make settings that will be read and converted to commands. I files a separate issue:

return this._targetPlatformPromise; } <del> async scanAllExtensions(systemScanOptions: ScanOptions, userScanOptions: ScanOptions): Promise<IScannedExtension[]> { </del> <ins> async scanAllExtensions(systemScanOptions: ScanOptions, userScanOptions: ScanOptions, includeExtensionsUnderDev: boolean): Promise<IScannedExtension[]> { </ins> const [system, user] = await Promise.all([ this.scanSystemExtensions(systemScanOptions), this.scanUserExtensions(userScanOptions), ]); <del> const development = await this.scanExtensionsUnderDevelopment(systemScanOptions, [...system, ...user]); </del> <ins> const development = includeExtensionsUnderDev ? await this.scanExtensionsUnderDevelopment(systemScanOptions, [...system, ...user]) : []; </ins> return this.dedupExtensions(system, user, development, await this.getTargetPlatform(), true); }


Question:
Our presubmit tests started to fail consistently since our test setup picked up code 1.67.0 yesterday. Our test is basically doing first, run written with from after the extension tests succeed, run a check on the consistency between our file and documentation/settings info. After running the extension tests with 1.67.0, it looks like the second step that involves reading sees a differently formatted Actually, it's not only a differently formatted , but it includes a new property (, , ...) at the end. The test passes if I make the extension tests to use 1.66.2. We can work around by arranging our presubmit test order or rewriting our test logic to handle this. But, we want to understand what is going on behind the scene and why this modification is necessary. Thanks!
this looks suspicious...
This is designed and expected. It is the metadata VS Code stores per extension while installing that can be used later for other features like updating etc., So I would recommend your extension to handle this.
this has started breaking our extension's tests without warning, and moreover, the way it writes to it's modifying the whole file (looks like whitespace changes).
how have you gone about working around this breaking change? I'm trying to get a release out myself and am suddenly blocked
Whelp, something else went on that broke my tests, but definitely noticed this too and will need to be careful about not committing the reformatted .
Sorry about the caused breakage. I am not sure what is your test doing, but I think it's not a good idea to depend on the content of , because VS Code uses it to write metadata about the extension. We do not remove any existing data but add more data.
What's the recommended way of dealing with the property when testing an extension with set to a version-controlled source directory? Should the changes be committed or do extension authors have to take care of reverting it (which probably means parsing and clearing the property).
I'm currently reverting it. Would love to know if we should do otherwise.
Reopening this to investigate if there is something changed on VS Code while running extension tests
I wanted to re-report this issue, because it was previously misunderstood and closed. Of course I won’t now this is open, but I already typed out reproduction steps. Perhaps they help. Steps to Reproduce: a git repository (this makes the issue more clear) a minimal VSCode extension with a test. The issue becomes more apparent if an existing extension name / publisher is used. .gitignore and commit we actually reproduce the bug. Run the extension tests Note that running tests has modified . Formatting is changed to use tabs, the final newline is stripped, and publisher metadata is to the file.
To verify: Create some hello world extension and open it's and change the and properties to an extension that already exists in Marketplace. Eg:Quit Code Insiders and Start from CLI with following arguments Make sure hello world extension's is not updated with property
This looks related to which didn't have anything to do with testing the extension, but only debugging it, and getting the same metadata written to an "unsuspecting" Will this fix handle this SO situation as well? The problem occurred very rarely so I couldn't give steps to reproduce, but I was only debugging and not running tests on the extension.
Yes
I have learned more about my situation of getting this extra data when debugging an extension. It happens when the extension writes to the . I have a couple of extensions which allow the user to make settings that will be read and converted to commands. I files a separate issue:

const userScanOptions: ScanOptions = { includeInvalid: true, profileLocation }; let scannedExtensions: IScannedExtension[] = []; if (type === null || type === ExtensionType.System) { <del> scannedExtensions.push(...await this.extensionsScannerService.scanAllExtensions({ includeInvalid: true }, userScanOptions)); </del> <ins> scannedExtensions.push(...await this.extensionsScannerService.scanAllExtensions({ includeInvalid: true }, userScanOptions, false)); </ins> } else if (type === ExtensionType.User) { scannedExtensions.push(...await this.extensionsScannerService.scanUserExtensions(userScanOptions)); }


Question:
Request refactorings, and extract to a function at the top-level. Expected: no crash Actual: I'm not sure on the specific version, but in the last 9 days or so we started seeing the following crash:
Actually I found this while trying to repro a different bug. The one I was looking to repro had the following stack trace: <details<summaryOriginal Stack Trace </summary</details I think this actually only repros when working in an anonymous buffer in VS Code. When you ask for a refactoring on an anonymous buffer, we come back with the same buffer name However, VS Code pops up a notification that "You cannot rename this element" and creates a new buffer with the contents. This confuses TSServer a lot, and makes it fail over and over again.
I initially read the last part of the issue title as “thanks, language service” and thought the sarcasm was appropriate.
I may steal that in the future :D
can you transfer this issue to VSCode if appropriate?
Did this just start happening with the latest insiders?
Possible introduced with
Yeah, I believe it didn't repro on a 2 week old nightly, but I can't 100% confirm.
<!-- 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!

export default class TypeScriptServiceClient extends Disposable implements ITypeScriptServiceClient { private readonly pathSeparator: string; <ins> private readonly emptyAuthority = 'ts-nul-authority'; </ins> private readonly inMemoryResourcePrefix = '^'; private readonly workspaceState: vscode.Memento;


Question:
Request refactorings, and extract to a function at the top-level. Expected: no crash Actual: I'm not sure on the specific version, but in the last 9 days or so we started seeing the following crash:
Actually I found this while trying to repro a different bug. The one I was looking to repro had the following stack trace: <details<summaryOriginal Stack Trace </summary</details I think this actually only repros when working in an anonymous buffer in VS Code. When you ask for a refactoring on an anonymous buffer, we come back with the same buffer name However, VS Code pops up a notification that "You cannot rename this element" and creates a new buffer with the contents. This confuses TSServer a lot, and makes it fail over and over again.
I initially read the last part of the issue title as “thanks, language service” and thought the sarcasm was appropriate.
I may steal that in the future :D
can you transfer this issue to VSCode if appropriate?
Did this just start happening with the latest insiders?
Possible introduced with
Yeah, I believe it didn't repro on a 2 week old nightly, but I can't 100% confirm.
<!-- 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!

{ return this.inMemoryResourcePrefix + '/' + resource.scheme <del> + '/' + resource.authority </del> <ins> + '/' + (resource.authority || this.emptyAuthority) </ins> + (resource.path.startsWith('/') ? resource.path : '/' + resource.path) + (resource.fragment ? '#' + resource.fragment : ''); }


Question:
Request refactorings, and extract to a function at the top-level. Expected: no crash Actual: I'm not sure on the specific version, but in the last 9 days or so we started seeing the following crash:
Actually I found this while trying to repro a different bug. The one I was looking to repro had the following stack trace: <details<summaryOriginal Stack Trace </summary</details I think this actually only repros when working in an anonymous buffer in VS Code. When you ask for a refactoring on an anonymous buffer, we come back with the same buffer name However, VS Code pops up a notification that "You cannot rename this element" and creates a new buffer with the contents. This confuses TSServer a lot, and makes it fail over and over again.
I initially read the last part of the issue title as “thanks, language service” and thought the sarcasm was appropriate.
I may steal that in the future :D
can you transfer this issue to VSCode if appropriate?
Did this just start happening with the latest insiders?
Possible introduced with
Yeah, I believe it didn't repro on a 2 week old nightly, but I can't 100% confirm.
<!-- 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!

} if (filepath.startsWith(this.inMemoryResourcePrefix)) { <del> const parts = filepath.match(/^^/([^/]+)/(.+)$/); </del> <ins> const parts = filepath.match(/^^/([^/]+)/([^/]*)/(.+)$/); </ins> if (parts) { <del> const resource = vscode.Uri.parse(parts[1] + '://' + parts[2]); </del> <ins> const resource = vscode.Uri.parse(parts[1] + '://' + (parts[2] === this.emptyAuthority ? '' : parts[2]) + '/' + parts[3]); </ins> return this.bufferSyncSupport.toVsCodeResource(resource); } }


Question:
<img width="628" alt="image" src="https://user-"I often by accident click on the wrong button when adding a comment, imho this action is way too prominent there because it seems like the primary button to add the comment. //cc also because both buttons have the same color <img width="306" alt="image" src="https://user-"
The "Go to Review" button was to address confusion on how to complete a review: We could add some convention where the left-most button gets more prominent styling. what do you think?
Catching up after a week off.. I believe we should follow the same patterns used for dialogs and notifications where a single primary button is used alongside one or more secondary buttons. From what I understand, our the order the buttons in a dialog depends on the OS. Windows gets left-aligned primary buttons, vice versa for macOS. In this case, since the buttons are always right-aligned to the comment input on any platform, I think the primary button should be on the far right to align with the edge of the container. This looks to already be the case elsewhere in the extension: <img width="423" alt="CleanShot 2022-04-18 at 09 09 03 src="https://user-"
Thanks I want to update the style of this button to be a primary button, but there may be extensions that flip the order of importance for their buttons. I'll poll some other folks and see if it seems ok.
Verified. I assume that Go to Review button is renamed to Start Review !
The Start Review button is a Go to Review button once you have already started a review. But since you verified the button colors this is still verified.

this._buttonElements.forEach(b => b.remove()); const groups = menu.getActions({ shouldForwardArgs: true }); <ins> let isPrimary: boolean = true; </ins> for (const group of groups) { const [, actions] = group; this._actions = actions; <del> actions.forEach(action => { const button = new Button(this.container); </del> <ins> for (const action of actions) { const button = new Button(this.container, { secondary: !isPrimary }); isPrimary = false; </ins> this._buttonElements.push(button.element); this._toDispose.add(button);


Question:
<img width="628" alt="image" src="https://user-"I often by accident click on the wrong button when adding a comment, imho this action is way too prominent there because it seems like the primary button to add the comment. //cc also because both buttons have the same color <img width="306" alt="image" src="https://user-"
The "Go to Review" button was to address confusion on how to complete a review: We could add some convention where the left-most button gets more prominent styling. what do you think?
Catching up after a week off.. I believe we should follow the same patterns used for dialogs and notifications where a single primary button is used alongside one or more secondary buttons. From what I understand, our the order the buttons in a dialog depends on the OS. Windows gets left-aligned primary buttons, vice versa for macOS. In this case, since the buttons are always right-aligned to the comment input on any platform, I think the primary button should be on the far right to align with the edge of the container. This looks to already be the case elsewhere in the extension: <img width="423" alt="CleanShot 2022-04-18 at 09 09 03 src="https://user-"
Thanks I want to update the style of this button to be a primary button, but there may be extensions that flip the order of importance for their buttons. I'll poll some other folks and see if it seems ok.
Verified. I assume that Go to Review button is renamed to Start Review !
The Start Review button is a Go to Review button once you have already started a review. But since you verified the button colors this is still verified.

button.enabled = action.enabled; button.label = action.label; <del> }); </del> <ins> } </ins> } }


Question:
<img width="628" alt="image" src="https://user-"I often by accident click on the wrong button when adding a comment, imho this action is way too prominent there because it seems like the primary button to add the comment. //cc also because both buttons have the same color <img width="306" alt="image" src="https://user-"
The "Go to Review" button was to address confusion on how to complete a review: We could add some convention where the left-most button gets more prominent styling. what do you think?
Catching up after a week off.. I believe we should follow the same patterns used for dialogs and notifications where a single primary button is used alongside one or more secondary buttons. From what I understand, our the order the buttons in a dialog depends on the OS. Windows gets left-aligned primary buttons, vice versa for macOS. In this case, since the buttons are always right-aligned to the comment input on any platform, I think the primary button should be on the far right to align with the edge of the container. This looks to already be the case elsewhere in the extension: <img width="423" alt="CleanShot 2022-04-18 at 09 09 03 src="https://user-"
Thanks I want to update the style of this button to be a primary button, but there may be extensions that flip the order of importance for their buttons. I'll poll some other folks and see if it seems ok.
Verified. I assume that Go to Review button is renamed to Start Review !
The Start Review button is a Go to Review button once you have already started a review. But since you verified the button colors this is still verified.

padding: 10px 0; } <del> .review-widget .body .edit-container .form-actions { display: flex; justify-content: flex-end; } </del> .review-widget .body .edit-textarea { height: 90px; margin: 5px 0 10px 0;


Question:
<img width="628" alt="image" src="https://user-"I often by accident click on the wrong button when adding a comment, imho this action is way too prominent there because it seems like the primary button to add the comment. //cc also because both buttons have the same color <img width="306" alt="image" src="https://user-"
The "Go to Review" button was to address confusion on how to complete a review: We could add some convention where the left-most button gets more prominent styling. what do you think?
Catching up after a week off.. I believe we should follow the same patterns used for dialogs and notifications where a single primary button is used alongside one or more secondary buttons. From what I understand, our the order the buttons in a dialog depends on the OS. Windows gets left-aligned primary buttons, vice versa for macOS. In this case, since the buttons are always right-aligned to the comment input on any platform, I think the primary button should be on the far right to align with the edge of the container. This looks to already be the case elsewhere in the extension: <img width="423" alt="CleanShot 2022-04-18 at 09 09 03 src="https://user-"
Thanks I want to update the style of this button to be a primary button, but there may be extensions that flip the order of importance for their buttons. I'll poll some other folks and see if it seems ok.
Verified. I assume that Go to Review button is renamed to Start Review !
The Start Review button is a Go to Review button once you have already started a review. But since you verified the button colors this is still verified.

margin-bottom: 5px; } <del> .review-widget .body .comment-form .monaco-text-button { </del> <ins> .review-widget .body .form-actions .monaco-text-button { </ins> float: right; }