jiebi/CodeConvo huggingface dataset:
Change:
Start VS Code from fresh user data directory and extensions directory Reload Window Welcome page is broken Sanity checking VSCodeSetup-ia32-1.78.0. When launching VS Code the welcome screen opens but content never shows up ! I tested the install in a Windows Sandbox close the welcome screen close VS Code open VS Code again opens with working welcome screen.
Closing VS Code and reopening it ended it the same endless loop in the welcome screen.
Same behavior with the Zip install.
Did not happen with the User install. May be some timing issue.
Workaround close the welcome screen close VS Code open VS Code again opens with working welcome screen.
Starting with a fresh Sandbox revealed the same behavior.
Do you see any errors in the console?
Nothing in the console <img width="993" alt="capture" src="https://user-"
Found this in the extension host log:
Exception is also present when Welcome page opens correctly.
based on the error from , looks like this commit was not released and consumed in VSCode
Created separate issue for module loading - . I believe these two are unrelated.
Yes I also believe those are unrelated: Welcome screen works well for me, but I can see the same error in extension host.
A custom version of (that does not disable the welcome screen), hints to this commit range:
Some things I know It only happens when the welcome page is opening during startup- if you disable the welcome page and open it manually, it works It sometimes starts working, then doesn't break again (see Dirk's workaround above) It seems to usually work when I haven't disabled all my extensions Here's what I see when I debug in devtools 64-bit build at , is undefined 32-bit build is is empty we wait on , this never resolves In the service at , this is never called, makes sense since there are no extensions. That code is suspicious

Discussion:
"main": "./out/extension", "browser": "./dist/browser/extension", "contributes": { <ins> "walkthroughs": [ { "id": "tempNodejsWelcome", "title": "tempNodejsTitle", "description": "tempNodejsDescription", "steps": [], "when": "false" } ], </ins> "jsonValidation": [ { "fileMatch": "package.json",
Change:
type at the end of line have ghost text accept it word by word when reaching the end of the viewport accepted words aren't revealed https://user-
fyi that I have pushed as a fix for this
Thank you! Sorry for not fixing this, I thought the fix was more complicated.
Accepting single word seems to move the horizontal scroll, but tabbing to accept the whole line does not scroll. Is that expected?
Marking as verified as word by word works.

Discussion:
import { Selection } from 'vs/editor/common/core/selection'; import { SingleTextEdit, TextEdit } from 'vs/editor/common/core/textEdit'; import { TextLength } from 'vs/editor/common/core/textLength'; <ins> import { ScrollType } from 'vs/editor/common/editorCommon'; </ins> import { Command, InlineCompletionContext, InlineCompletionTriggerKind, PartialAcceptTriggerKind } from 'vs/editor/common/languages'; import { ILanguageConfigurationService } from 'vs/editor/common/languages/languageConfigurationRegistry'; import { EndOfLinePreference, ITextModel } from 'vs/editor/common/model';

const selections = getEndPositionsAfterApplying(edits).map(p => Selection.fromPositions(p)); editor.executeEdits('inlineSuggestion.accept', edits.map(edit => EditOperation.replace(edit.range, edit.text))); editor.setSelections(selections, 'inlineCompletionPartialAccept'); <ins> editor.revealPositionInCenterIfOutsideViewport(editor.getPosition()!, ScrollType.Immediate); </ins> } finally { this._isAcceptingPartially = false; }
Change:
Type: <bBug</bI have the setting: "Git: Close Diff On Operation" enabled. Staging a change will close the diff. Committing a staged change will close the diff. But if I just click the Commit button, the changes will commit but the diff won't close. Reproduction steps: & save a file the file in "Source Control" to open a diff Commit Expected behavior: The "(Working Tree)" tab closes Actual behavior: It stays open VS Code version: Code 1.77.3 (Universal) (, 2023-04-12T09:19:37.325Z) OS version: Darwin x64 22.4.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (22)</summaryExtensionVersion ------ tailwind-documentation0.1.6 ng-template15.2.1 tailwind-docs2.0.0 docs-view0.0.11 vscode-tailwindcss0.9.11 language-postcss1.1.0 vscode-deno3.17.0 vscode-axe-linter4.7.0 nasc-touchbar1.12.0 copilot1.84.51 vscode-test-explorer2.21.1 tasks-statusbar0.1.0 git-graph1.30.0 dotenv1.0.1 csharp1.25.4 test-adapter-converter0.1.7 vsliveshare1.0.5864 vscode-yaml1.12.2 snyk-vulnerability-scanner1.18.2 code-spell-checker2.20.4 vscode-todo-highlight1.0.5 pretty-ts-errors0.4.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --

Discussion:
} async commit(message: string | undefined, opts: CommitOptions = Object.create(null)): Promise<void> { <ins> const indexResources = [...this.indexGroup.resourceStates.map(r => r.resourceUri.fsPath)]; const workingGroupResources = opts.all && opts.all !== 'tracked' ? [...this.workingTreeGroup.resourceStates.map(r => r.resourceUri.fsPath)] : []; </ins> if (this.rebaseCommit) { await this.run( Operation.RebaseContinue,

} await this.repository.rebaseContinue(); <del> await this.commitOperationCleanup(message, opts); </del> <ins> await this.commitOperationCleanup(message, indexResources, workingGroupResources); </ins> }, () => this.commitOperationGetOptimisticResourceGroups(opts)); } else {

} await this.repository.commit(message, opts); <del> await this.commitOperationCleanup(message, opts); </del> <ins> await this.commitOperationCleanup(message, indexResources, workingGroupResources); </ins> }, () => this.commitOperationGetOptimisticResourceGroups(opts));

} } <del> private async commitOperationCleanup(message: string | undefined, opts: CommitOptions) { </del> <ins> private async commitOperationCleanup(message: string | undefined, indexResources: string[], workingGroupResources: string[]) { </ins> if (message) { this.inputBox.value = await this.getInputTemplate(); } <del> const indexResources = [...this.indexGroup.resourceStates.map(r => r.resourceUri.fsPath)]; const workingGroupResources = opts.all && opts.all !== 'tracked' ? [...this.workingTreeGroup.resourceStates.map(r => r.resourceUri.fsPath)] : []; </del> this.closeDiffEditors(indexResources, workingGroupResources); }
Change:
cursor is rendered on top of it <img width="400" src="https://user-"Version: 1.78.0 Commit: Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.78.0 Chrome/108.0.5359.215 Electron/22.4.8 Safari/537.36
Hi thank you for filing the issue. I tried to reproduce this issue, but it seems to work fine on my computer. Could you please try spawning a color picker in the latest VS Code Insiders (). If you continue seeing this issue, could you please try to run VS Code Insiders without any extensions and reproduce this error? It so happens sometimes that extensions cause errors. If you still see this issue, do you think you could copy paste below a minimally reproducible example of the contents of the editor where this happens?
<details</summary</details! Maybe it only reproduces with zoom? Should it render like that with markers? !
Hi, thanks for the reply, could you post here a copy of your settings file. I am thinking this error could be happening in relation to one of your settings.
Hmmm, it's a 2000 line-long file, not sure how useful it would be. It looks like I can reproduce it on the web with browser zoom and . On desktop that would be:

Discussion:
super(); this._standaloneColorPickerVisible.set(true); this._standaloneColorPickerParticipant = _instantiationService.createInstance(StandaloneColorPickerParticipant, this._editor); <del> this._position = this._editor._getViewModel()?.getPrimaryCursorState().viewState.position; </del> <ins> this._position = this._editor._getViewModel()?.getPrimaryCursorState().modelState.position; </ins> const editorSelection = this._editor.getSelection(); const selection = editorSelection ? {
Change:
Running commands in a normal bash terminal retains the history (of the commands ran) but the same is not true for VS Code. So after closing VSCode all of the command history is deleted and the user has to remember any complex command that they ran. Ideally we would want our history to be stored in .bashhistory or if VS Code doesn't want to touch user files, in .vscodebash_history perhaps?
This works for me
Doesn't work for me either, tried deleting and re-installing, no dice.
Maybe this is a remote issue
More reports here:
This affects me on my MacBook Pro as well. It's a problem 100% of the time, it's not intermittent. I'm guessing it's not a remote issue, as it happens when I'm using a completely local folder without any sort of remote functionality. There are several other reports of this issue in as well. If I type to close the terminal before I quit VS Code, the history is saved like it should be. If I quit VS Code without doing that, the history is lost. This is a recent issue (within the last couple of months or so), it used to work correctly. Happy to provide any other info that can help diagnose this, as I can always reproduce it.
Yes, the history save feature works if I type or to close the terminal. Doing it by any other way (like clicking the trash button to close the terminal) does not save the history.
I think that I have found the issue. In this line, we are sending instead of , hence the process gets killed without the chance to write the history to the file () However it seems that this change was made because the terminal subprocess (running ) couldn't be killed because the are also gobbling up any signal. Hence this issue I think the solution to this can be done by creating a function something like : (relevant discussion in ) That way, the signal can be intercepted and exited as needed.
If it is possible, could you help me to write a patch to fix this issue? :smile: I have tried patching the function in the file to trap however, I am having trouble getting it to work.

Discussion:
if (this._ptyProcess) { await this._throttleKillSpawn(); this._logService.trace('IPty#kill'); <del> this._ptyProcess.kill(!isWindows ? 'SIGKILL' : undefined); </del> <ins> this._ptyProcess.kill(); </ins> } } catch (ex) { // Swallow, the pty has already been killed
Change:
<!-- 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. --is great! It seems to currently only support the six- and eight-value syntaxes, and . It'd be useful to support the three- and four-value syntaxes, and . (Spec: MDN: ) For example this code in a JS file renders for me as !
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
To test this issue: on the setting . any file and write a hex value in the editor of length three or four. Verify that a color decorator is rendered next to the hex value.
Thank you! For anyone who finds this issue and thinks it still isn't supported, make sure you've also disabled any plugins which contribute decorators <img width="132" alt="image" src=""

Discussion:
function computeColors(model: IDocumentColorComputerTarget): IColorInformation[] { const result: IColorInformation[] = []; // Early validation for RGB and HSL <del> const initialValidationRegex = /b(rgb|rgba|hsl|hsla)(([0-9s,.%]*))|(#)([A-Fa-f0-9]{6})b|(#)([A-Fa-f0-9]{8})b/gm; </del> <ins> const initialValidationRegex = /b(rgb|rgba|hsl|hsla)(([0-9s,.%]*))|(#)([A-Fa-f0-9]{3})b|(#)([A-Fa-f0-9]{4})b|(#)([A-Fa-f0-9]{6})b|(#)([A-Fa-f0-9]{8})b/gm; </ins> const initialValidationMatches = _findMatches(model, initialValidationRegex); // Potential colors have been found, validate the parameters
Change:
<!-- 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.79.0-insider Commit: Date: 2023-05-04T22:11:08.187Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code-Insiders/1.79.0-insider Chrome/108.0.5359.215 Electron/22.4.8 Safari/537.36 Steps to Reproduce: (Video attached) a new VS Code window and when the window is open, press to open recent folders top panel panel disappears when the page is rendered https://user-
This issue does not occur when the setting is set
I reported this as well three months ago: I don't understand why there's so few users with this issue. Opening a recent folder is basically the first thing you do after launching vscode.
May be most users have disabled the Welcome page
I have but only because of this issue
I think the welcome view grabs focus when it opens after quick open has been opened and thus quick open closes. You can configure in settings to keep quick open open in that case:
I feel like a better approach for this one is: understand why the Welcome page opens so late. understand why the Welcome page steals focus I think the first would be a better one to focus on. My expectation would be that the Welcome page opens with VS Code, rather than being delayed.
The welcome page relies on the gallery service, experiment service which could be slow to startup. Im working on fix to only load the welcome page once all the services are readied. The issue of it stealing focus after load still needs to be fixed though.

Discussion:
} override focus() { <del> this.container.focus(); </del> <ins> const active = document.activeElement; let parent = this.container.parentElement; while (parent && parent !== active) { parent = parent.parentElement; } if (parent) { // Only set focus if there is no other focued element outside this chain. // This prevents us from stealing back focus from other focused elements such as quick pick due to delayed load. this.container.focus(); } </ins> } }
Change:
<!-- 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: code -v: 1.78.0 arm64 OS Version: macOS monterey 12.4 Steps to Reproduce: i use macOS origin input to type chinese in left sider search input, when i want to use arrow down to select target chinese word. the input content changed by arrow down. there is a reproduce video. https://user-

Discussion:
when: ContextKeyExpr.and( ContextKeyExpr.has(HistoryNavigationWidgetFocusContext), ContextKeyExpr.equals(HistoryNavigationBackwardsEnablementContext, true), <ins> ContextKeyExpr.not('isComposing'), </ins> historyNavigationVisible.isEqualTo(false), ), primary: KeyCode.UpArrow,

when: ContextKeyExpr.and( ContextKeyExpr.has(HistoryNavigationWidgetFocusContext), ContextKeyExpr.equals(HistoryNavigationForwardsEnablementContext, true), <ins> ContextKeyExpr.not('isComposing'), </ins> historyNavigationVisible.isEqualTo(false), ), primary: KeyCode.DownArrow,
Change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --We ran into this at Google: Currently, VSCode will use (like many debuggers) for stepping over on Electron, but on Web. The rationale, according to the code comment, is that browsers will not allow you to bind F10: I believe that is not fully correct: VSCode itself uses F10 (curiously exactly when in the browser), to focus the file menu: I changed the shortcut to F10 in the settings, and in my browser (Chrome on OS X) it worked fine - maybe it does not work on specific browsers? you removed for step over on web in - do you recall the exact reason? you the for application menu on web - why is this only on web? I would like to better understand if we can somehow make this work, as users generally expect to step over in debuggers, and having to type for step over, when e.g. step in is just is causing friction.
Besides the inconsistency between step in and step over shortcuts, and web and electron, another issue with is that this is "Toggle Maximization State" in Gnome:
I do not remember the exact reason. It seems like some browsers do not support this. Can you please try it out in Safari, Firefox, Edge and Chrome? And if it works across all browsers then maybe we can change this. Though I leave the decision up to who owns debug.
If I could confirm that it works on the four mentioned browsers, would you be open to changing this?
It works fine for me too in Edge on macOS. But yeah, if you could do a little testing in different browsers, and on Windows, I would set F10 by default. I suppose I have to keep alt+F10 as an alternate keybinding on web to not confuse people, hm
It's not explicitly stated where it in this issue , but I believe the only reason the menu focus F10 keybinding is web specific is because all other platforms had pre-existing methods that didn't work in web.
Sorry for the delay. I have tested with Github Codespaces (because does not support debugging) on Windows: Edge Version 113.0.1774.50 (Official build) (64-bit) Chrome 113.0.5672.127 (Offizieller Build) (64-Bit) (cohort: Stable) Firefox 113.0.2 (64-Bit) Would that suffice to support stepping with F10 in addition to Alt-F10 on Web? Do you need me to send a PR or are you making the change yourself Rob?
Thanks for trying that. I would take a PR for it
Thanks!

Discussion:
KeybindingsRegistry.registerCommandAndKeybindingRule({ id: STEP_OVER_ID, weight: KeybindingWeight.WorkbenchContrib, <del> primary: isWeb ? (KeyMod.Alt | KeyCode.F10) : KeyCode.F10, // Browsers do not allow F10 to be binded so we have to bind an alternative </del> <ins> primary: KeyCode.F10, secondary: isWeb ? [(KeyMod.Alt | KeyCode.F10)] : undefined, // Keep Alt-F10 for web for backwards-compatibility </ins> when: CONTEXT_DEBUG_STATE.isEqualTo('stopped'), handler: async (accessor: ServicesAccessor, _: string, context: CallStackContext | unknown) => { const contextKeyService = accessor.get(IContextKeyService);
Change:
In our accessibility user study testing, a user found that the start debugging button lacked a label. We should fix this even though the property does get read by some screen readers currently - such as VoiceOver.

Discussion:
const keybindingLabel = keybinding ? ` (${keybinding})` : ''; this.start.title = this.action.label + keybindingLabel; this.start.setAttribute('role', 'button'); <ins> this.start.ariaLabel = this.start.title; </ins> this.toDispose.push(dom.addDisposableListener(this.start, dom.EventType.CLICK, () => { this.start.blur();
Change:
<!-- 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. --Currently, it is treated as . (I have disabled all my extensions and confirm this behavior) It does support as comment like does. A simple workaround now is to set But it's nice to have it built in supported.
Clone the repository Open the repository in VS Code Insiders Rename to Open the file: Confirm that the file type is detected as "Ignore" Confirm that the comments in the file are coloured correctly

Discussion:
], "extensions": [ ".gitignore_global", <del> ".gitignore" </del> <ins> ".gitignore", ".git-blame-ignore-revs" </ins> ], "configuration": "./languages/ignore.language-configuration.json" }
Change:
This diff confused me for a bit. ! There's a trailing space at the end of the line but it's not highlighted. This would be even more confusing if you have non-visible whitespace (I think that's the default).
I bet you disabled whitespace diffing. Why should this setting be ignored now?
I have set, which means whitespace should show right? Setting to true doesn't show it either. Am I looking at the wrong setting? The why even if it's ignored is I click for more info and it shows nothing which confused me, I can understand why you wouldn't want to handle it specially though.

Discussion:
readOnly: false, renderIndicators: false, diffAlgorithm: 'advanced', <ins> ignoreTrimWhitespace: false, </ins> stickyScroll: { enabled: false } };
Change:
enable sticky scroll open a diff editor in a TS file toggle inline diff observe that the original line numbers are garbled We could disable sticky scroll in the original editor when the diff editor is rendered to be inline here --

Discussion:
// never wrap hidden editor result.wordWrapOverride1 = 'off'; result.wordWrapOverride2 = 'off'; <ins> result.stickyScroll = { enabled: false }; </ins> } else { result.wordWrapOverride1 = this._options.diffWordWrap; }

// never wrap hidden editor result.wordWrapOverride1 = 'off'; result.wordWrapOverride2 = 'off'; <ins> result.stickyScroll = { enabled: false }; </ins> } else { result.wordWrapOverride1 = this._options.get().diffWordWrap; }