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

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

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

Related discussion:
text: "colors": { // Base // "foreground": "", <del> "focusBorder": "#D3AF86", </del> <ins> "focusBorder": "#b49471", </ins> // "contrastActiveBorder": "", // "contrastBorder": "", // "widget.shadow": "",
Code change:
open vscode for web on macOS ctrl+click into a tab that is not active context menu opens but also the tab opens fyi this is similar to and requires the same fix. Interestingly on Electron this does not seem to be an issue, maybe produces context menu event in Electron but not in Web?

Related discussion:
text: const handleTitleClickOrTouch = (e: MouseEvent | GestureEvent): void => { let target: HTMLElement; if (e instanceof MouseEvent) { <del> if (e.button !== 0 || (isMacintosh && e.ctrlKey)) { return undefined; // only for left mouse click (ctrl+click on macos is right-click) </del> <ins> if (e.button !== 0 /* middle/right mouse button */ || (isMacintosh && e.ctrlKey /* macOS context menu */)) { return undefined; </ins> } target = e.target as HTMLElement;
Code change:
open vscode for web on macOS ctrl+click into a tab that is not active context menu opens but also the tab opens fyi this is similar to and requires the same fix. Interestingly on Electron this does not seem to be an issue, maybe produces context menu event in Electron but not in Web?

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

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

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

Related discussion:
text: maxHeight = Math.min(maxHeight, this._hover.containerDomNode.clientHeight); this._hover.containerDomNode.style.maxHeight = `${maxHeight}px`; <ins> if (this._hover.contentsDomNode.clientHeight > maxHeight) { this._hover.contentsDomNode.style.height = `${maxHeight}px`; } if (this._hover.contentsDomNode.clientHeight < this._hover.contentsDomNode.scrollHeight) { // Add padding for a vertical scrollbar const extraRightPadding = `${this._hover.scrollbar.options.verticalScrollbarSize}px`; if (this._hover.contentsDomNode.style.paddingRight !== extraRightPadding) { this._hover.contentsDomNode.style.paddingRight = extraRightPadding; } } </ins> } private setHoverPointerPosition(target: TargetRect): void {
Code change:
Does this issue occur when all extensions are disabled?: No VS Code Version: 1.73.1 OS Version: Windows_NT x64 10.0. Steps to Reproduce: ! to the extension bar. to hover some items. Some one may not show the default scroll bar, but the problem is exists. ! I have tried to fix it. It seems caused by the visual bug from the issue . The scroll bar will show when the content is too long. This solution is great, but it causes another little bug in the screenshot. I think it's unwise to remove the tag, so I tried another way, just add to the tag : ! I'll make a PR after this issue has submitted.
I can't reproduce this srollbar for all extensions in the list: !
This bug is not 100% recurring. Some extensions' descriptions may just exceed the calculated.
What's ur testing extension id?
These extensions have the problem on my machine.
! !
Maybe it's related to high-resolution screen. I'm sure it's an accidental problem, but it still exists. If you have the conditions, try adjusting the screen resolution scale to 150%.
there should be some bugs when doing sub pixel sampling whether it's related to windows DPI settings. can you reproduce this regularly without changing DPI?
Caused by can you please have a look at this?

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

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

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

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