jiebi/CodeConvo huggingface dataset:
Change:
result.push({ task, location: new Location(packageJsonUri, nameRange) }); } <del> // always add npm install (without a problem matcher) result.push({ task: await createTask(packageManager, INSTALL_SCRIPT, [INSTALL_SCRIPT], folder, packageJsonUri, 'install dependencies from package', []) }); </del> <ins> if (!workspace.getConfiguration('npm', folder).get<string[]>('scriptExplorerExclude', []).find(e => e.includes('install'))) { result.push({ task: await createTask(packageManager, INSTALL_SCRIPT, [INSTALL_SCRIPT], folder, packageJsonUri, 'install dependencies from package', []) }); } </ins> return result; }

Discussion:
<!-- 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.67.2 OS Version: Windows 11 Pro 21H2 Steps to Reproduce: a monorepo, in our case one that uses Yarn 3. at any non-root package in the NPM Scripts pane. The new unexpected behaviour is the appearance of an "install" script in every non-root package: <img src="https://user-" width="300"I suppose a virtual "install" script might have been nice to have in the monorepo root; instead it appears everywhere except for the monorepo root. Running the script just executes , which has the same behaviour regardless of the working directory in which it's invoked - it just installs all the dependencies for the full monorepo. Adding to does not make this go away. I haven't been able to find any mention of this new feature anywhere, so I'm not sure what the intended behaviour was; but I'm guessing it wasn't this!
We should exclude when its in .
or do you want to take this?
Just please note it's also strange that it shows up in every package except the monorepo root package. Since from anywhere in a monorepo will install the entire monorepo - I would hope an script would only show up in the monorepo root package. Obviously a minor bug, but also the kind of bug I can't fix myself since these parts are closed source :)
Please don't take this as pressure to create a PR , but this view and the tasks it shows are provided by the built in npm extension, which is in fact part of this OSS repo:
Change:
y18n "^4.0.0" yargs-parser "^18.1.2" <del> yargs@^17.2.1, yargs@^17.5.1: </del> <ins> yargs@^17.2.1: </ins> version "17.6.0" resolved "https://registry.yarnpkg.com/yargs/-/yargs-17.6.0.tgz#e134900fc1f218bc230192bdec06a0a5f973e46c" integrity sha512-8H/wTDqlSwoSnScvV2N/JHfLWOKuh5MVla9hqLjK3nsfyy6Y4kDSYSvkU5YCUEPOSnRXfIyx3Sq+B/IWudTo4g==

Discussion:
<img width="415" alt="image" src=""Looks localized here though, and hasn't changed in 13 months
language pack looks ok too... Looking into this some more... it seems that the new lines aren't being handled properly.
This still repros :/ is the loc pipeline maybe not running?
it is the newlines... which I thought I fixed... sigh... They are being escaped in the language pack: if I manually delete these extra slashes locally, the problem goes away.
Update... the text has change: Now it's using when it should use and I think I know why. So exporting looks find: is turned in to (we do this manually and it's the XML way to say ) but what we get from the translators... they replace with actual new lines That's not what I was expecting. I would expect them to use the encoded characters but they're not. hacky quick fix that fixes likely most of the scenarios: more accurate longer fix: now that I think about it, this is probably the correct workaround for extensions as well
<img alt="image" src=""Looks like it works now
Change:
resolveMimeTypes(textModel: NotebookTextModel, kernelProvides: readonly string[] | undefined): [readonly IOrderedMimeType[], number] { const mimeTypes = this._notebookService.getOutputMimeTypeInfo(textModel, kernelProvides, this.model); <del> let index = -1; if (this._pickedMimeType) { index = mimeTypes.findIndex(mimeType => mimeType.rendererId === this._pickedMimeType!.rendererId && mimeType.mimeType === this._pickedMimeType!.mimeType && mimeType.isTrusted); } // there is at least one mimetype which is safe and can be rendered by the core if (index === -1) { index = mimeTypes.findIndex(mimeType => mimeType.rendererId !== RENDERER_NOT_AVAILABLE && mimeType.isTrusted); } </del> <ins> const index = mimeTypes.findIndex(mimeType => mimeType.rendererId !== RENDERER_NOT_AVAILABLE && mimeType.isTrusted); </ins> return [mimeTypes, Math.max(index, 0)]; }

Discussion:
Steps: Clone VS Code Repo or open with GitHub Repos Install GHIN (make sure you haven't logged in to it) Open a notebook like the my- notebook Run See "log in" prompt and go through login flow Run notebook again See this: ! Possibly related... further up in the file, I notice some bad formatting of issues: ! Not sure if this is GHIN or Notebooks issue.
I think the previous output was not cleared when you rerun, when it's not the same mime type. A regression introduced recently. Good catch!
! another example
It looks much worse. It seems we are not even picking the right mime type.
Verifier, with the next Insiders Open endgame notebook Run all cells from the top toolbar On the first cell which has outputs, click the icon -Change Presentation -Choose Markdown Run all cells again Scroll the notebook to the end, there should be no outputs overlapped on each other (or output overlapping with markdown cell )
Change:
"resolved": "https://registry.npmjs.org/winreg/-/winreg-1.2.0.tgz" }, "xterm": { <del> "version": "2.8.1", "from": "Tyriar/xterm.js#vscode-release/1.15", "resolved": "git+https://github.com/Tyriar/xterm.js.git#75ffea5ebd5510ad0478b017c3946cb8d504855f" </del> <ins> "version": "2.9.1", "from": "Tyriar/xterm.js#vscode-release/1.16", "resolved": "git+https://github.com/Tyriar/xterm.js.git#74fde417c97962730a5fbbc8e8e7dcd47e1b897b" </ins> }, "yauzl": { "version": "2.8.0",

Discussion:
Upstream issue: Please verify this on Linux by opening tmux in mouse mode and ensuring regular mouse selection triggers "tmux selection" and shift+mouse selection triggers the regular terminal selection.
I thought I verified this last month?
this was Mac only last month, needs verification on Linux.

Scrolling within the integrated terminal doesn't scroll curses interfaces such as , , , etc. <!-- Use Help Report Issues to prefill these. --- VSCode Version: Version 1.15.0 OS Version: Arch Linux Shell: ZSH (oh-my-zsh) the integrated terminal ( ``) a curses style pager interface (e.g. , , , ) the mouse scrollwheel to try and scroll the pager happens, using keyboard commands to scroll works fine (, , , , arrow keys, etc) a seperate terminal (e.g. or ) step 2 & 3 above as expected; pager scrolls <!-- Launch with to check. --Reproduces without extensions: Yes
This should be fixed in the next version. Note that this only applies to applications that launch the alt buffer however, so it does not apply to . Upstream issue:
Sounds like the upstream issue might be a different one to this. It appears to be about the alternative buffer being rendered twice after a scroll. This is about passing scroll events to pager style programs, such as less and git log.
The reason scroll isn't making it to the terminal app is because the scrollbar is grabbing the event and not passing it to the terminal. When there is no scrollback it gets sent to the terminal correctly.
It works in tmux fine now but not vim yet.
This has been working for a few versions now
Change:
const matchingCandidates: Map<number, CandidatePort> = new Map(); const pidToPortsMapping: Map<number | undefined, number[]> = new Map(); forwardedPorts.forEach(forwardedPort => { <del> const matchingCandidate = mapHasAddressLocalhostOrAllInterfaces<CandidatePort>(this._candidates ?? new Map(), LOCALHOST_ADDRESSES[0], forwardedPort.port); </del> <ins> const matchingCandidate = mapHasAddressLocalhostOrAllInterfaces<CandidatePort>(this._candidates ?? new Map(), LOCALHOST_ADDRESSES[0], forwardedPort.port) ?? forwardedPort; </ins> if (matchingCandidate) { matchingCandidates.set(forwardedPort.port, matchingCandidate); <del> if (!pidToPortsMapping.has(matchingCandidate.pid)) { pidToPortsMapping.set(matchingCandidate.pid, []); </del> <ins> const pid = isCandidatePort(matchingCandidate) ? matchingCandidate.pid : undefined; if (!pidToPortsMapping.has(pid)) { pidToPortsMapping.set(pid, []); </ins> } <del> pidToPortsMapping.get(matchingCandidate.pid)?.push(forwardedPort.port); </del> <ins> pidToPortsMapping.get(pid)?.push(forwardedPort.port); </ins> } });

Discussion:
Testing When I try to return , , and aren't working for me. an extension as described in and create a ports attribute provider. the following to return one of the above actions: running the command, we just get a notification. :bug: I'm not sure whether this is happening because I'm in a devcontainer.
Hmm, I'm still seeing this in an alpine devcontainer. The previews/browsers should open immediately upon detection, right?
Verified using different verif steps than above.
Change:
readonly maximumWidth: number = Number.POSITIVE_INFINITY; get minimumHeight(): number { const value = this.isCommandCenterVisible ? 35 : 30; <del> return value / (this.currentMenubarVisibility === 'hidden' || getZoomFactor() < 1 ? getZoomFactor() : 1); </del> <ins> return value / (this.useCounterZoom ? getZoomFactor() : 1); </ins> } get maximumHeight(): number { return this.minimumHeight; } //#endregion

Discussion:
Code mac, have custom title bar in bar is not zooming in like the rest of the workbench To make the custom title bar accessible it needs to be zoomable. fyi
in general we've never done this. in fact on Windows we don't zoom in if the menubar is not present since the native title bar would not zoom. its up to the OS to decide the scale of the title bar. however, I do see a case to update the conditions if the new command center is present. what are your thoughts? further thing to consider. we can zoom in, but zooming out (below 1 zoom level) is not an option because the window controls have a minimum size.
I agree with you, and as we put more VS Code items in the title area I see a clear case to support zoom. Since the title area will feel more and more like an integral part of VS Code - and thus it should behave like the rest. Not being able to zoom out is fine imho. I feel that is the corner case. might also have thoughts, since we both noticed this bug when I was demoing the title bar search yesterday.
I think we need to work with Electron to also then zoom the native window controls, otherwise it looks like this: !
we can zoom in the controls, we just cannot zoom out, so that can be updated though the black bar is a separate issue that makes it look worse
1.67.2 TitleBar ! 1.68 TitleBar ! The new version is so small that it's hard to click
Agreed. Noticed this too after updating to v1.68. I use zoom : -1 but the title bar is still big and not zoomed out like the rest of the content
I have verified that the custom title bar can now we zoomable - thanks for that As you said zoom out is not supported which is fine, however on zoom out, the title bar does not change size but gets blurry. Like the browser anti aliasing rendering gets broken. Let me know if you would like me to file a new issue for this.
hmm yes, probably the way we implement counter zooming gives us this behavior, I don't think this is new however, nor do I think there is an easy fix for that. Would you mind verifying on stable for your machine?

If it is new, I would like a separate issue to investigate.
I can reproduce on stable. So I will not file an issue. If you still need one just let me know. Thanks!
Change:
import { AudioCue, IAudioCueService } from 'vs/platform/audioCues/browser/audioCueService'; import { IContextKey, IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; import { TerminalContextKeys } from 'vs/workbench/contrib/terminal/common/terminalContextKey'; <ins> import { withNullAsUndefined } from 'vs/base/common/types'; </ins> const enum CssClass { Active = 'active', Hide = 'hide' } <ins> interface IAccessibleBufferQuickPickItem extends IQuickPickItem { lineNumber: number; exitCode?: number; } </ins> export class AccessibleBufferWidget extends DisposableStore { private _accessibleBuffer: HTMLElement; private _bufferEditor: CodeEditorWidget;

Discussion:
Using here, I cannot enter the accessible buffer https://user-
The issue is that here, the default tab behavior is to focus the terminal tabs element edit: hard to repro, that's not the cause
ok this happens when is not applied to . See here that the buffer editor does get focused here, but you cannot see it https://user-
Repro: run some commands - - - Try to wasn't applied to so the accessible buffer isn't visible
https://user-

Currently when you use navigate accessible buffer you get a quick pick with the options, I expected changing these to scroll to the position without accepting it, and escape to revert to the original scroll position.
As part of this, providing ~1/3 of the viewport of context above would also be good
We'd need to think about how we to communicate the preview information to a screen reader user, as a pre"view" is usually visual
I don't think making this available to the screen reader makes sense, it would just complicate navigating the list. It is useful for sighted users though.
Oh I understand now - you mean on change of the active quick pick item, reveal the line and on enter, focus that line (as it already does)
Yep
To verify, in a terminal with shell integration, run some commands. to enter the accessible buffer. to . Without pressing , use the arrow keys to go between the options. It should scroll to the command if it is outside of the viewport.
Works but I opened
Change:
border-bottom: none; } <del> .monaco-editor .edit-context-composition-secondary { </del> <ins> .monaco-editor :not(.hc-black, .hc-light) .edit-context-composition-secondary { </ins> border-bottom: 1px solid var(--vscode-editor-compositionBorder); } <del> .monaco-editor .edit-context-composition-primary { </del> <ins> .monaco-editor :not(.hc-black, .hc-light) .edit-context-composition-primary { </ins> border-bottom: 2px solid var(--vscode-editor-compositionBorder); } <ins> .monaco-editor :is(.hc-black, .hc-light) .edit-context-composition-secondary { border: 1px solid var(--vscode-editor-compositionBorder); } .monaco-editor :is(.hc-black, .hc-light) .edit-context-composition-primary { border: 2px solid var(--vscode-editor-compositionBorder); } </ins>

Discussion:
Provided we continue going forward with changing the background of the selection during composition, we need to also change the color of the text when in the high and low contrast themes, otherwise it is no longer possible to see the text very well. There would not be enough contrast. The way it looks now: Here the word should be in black so we can see it clearly.
Another option is to add an outline/dashed outline/etc. to indicate composition? Inverting the background color is a bit extreme imo, imagine being a user and almost everything you type makes the background of the text flip. Doesn't feel like a good UX to me.
Hmm that is true, I haven't thought about that. Good idea :). Maybe I'll just add an outline then.
Change:
// update all decorations const oldDecorationsIds = this._decorationTypeKeysToIds[decorationTypeKey] || []; <del> this._decorationTypeKeysToIds[decorationTypeKey] = this.deltaDecorations(oldDecorationsIds, newModelDecorations); </del> <ins> this.changeDecorations(accessor => this._decorationTypeKeysToIds[decorationTypeKey] = accessor.deltaDecorations(oldDecorationsIds, newModelDecorations)); </ins> } public setDecorationsByTypeFast(decorationTypeKey: string, ranges: IRange[]): void {

Discussion:
Open the chat sidebar Type , pick from suggest widget Pick a file, so it reads eg Delete the full contents of the input with cmd+backspace Get this error I think I understand what's happening here. I have two listeners that each call . The first one runs, and after setting decorations, it calls to continue firing events, so my second listener runs, and also calls . And this is considered recursive because it happens before was decremented but isn't "really" recursive, to me. So is it bad practice to call synchronously inside ? Or is there something else I should be doing differently?
I think the actual problem is that is used here: This should use instead. Feel free to provide a PR.
Change:
isCueEnabled(cue: AudioCue): boolean; isAlertEnabled(cue: AudioCue): boolean; onEnabledChanged(cue: AudioCue): Event<void>; <ins> onAlertEnabledChanged(cue: AudioCue): Event<void>; </ins> playSound(cue: Sound, allowManyInParallel?: boolean): Promise<void>; playAudioCueLoop(cue: AudioCue, milliseconds: number): IDisposable;

Discussion:
Testing "Audio Cues: Line Has Warning" is set to false. "Accessibility Alert: Warning" is set to true. I generated a warning by using the Markdown Lint extension and writing text into a new Markdown file without an h1 header. When I turn on the audio cue, the accessibility alert also alerts me that there's a warning. When I turn off the audio cue but leave the accessibility alert on, the accessibility alert does not alert me that there's a warning.
I cannot seem to trigger a warning - can you pls give more specific instructions about how to do so? !
Install the extension. Then create a .md file and paste in the following The extension should already generate a warning.
Note this issue when verifying . When I tested using a screen reader, the warning only appeared once. Based on debugging (the call happens), I believe when using a braille device, this works.
Change:
if (node.getAttribute('href') === '#') { event.view.scrollTo(0, 0); } else if (node.hash && (node.getAttribute('href') === node.hash || (baseElement && node.href === baseElement.href + node.hash))) { <del> const fragment = node.hash.substr(1, node.hash.length - 1); const scrollTarget = event.view.document.getElementById(decodeURIComponent(fragment)); </del> <ins> const fragment = node.hash.slice(1); const scrollTarget = event.view.document.getElementById(fragment) ?? event.view.document.getElementById(decodeURIComponent(fragment)); </ins> scrollTarget?.scrollIntoView(); } else { hostMessaging.postMessage('did-click-link', node.href.baseVal || node.href);

Discussion:
Issue Type: <bBug</bExample markdown: Click to the link navigates to the proper heading in the editor in all 3 cases. But in the rendered preview window only works. Reproduces since 1.62.0, was OK in 1.61.2. VS Code version: Code - Insiders 1.64.0-insider (, 2021-12-22T05:15:28.225Z) OS version: Windows_NT x64 10.0. Restricted Mode: No Extensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
gets . () gets . () Here, only can find the element successfully. However, the webview fails. : : Thus, The method uses ordinal comparison. Thus, The example in by is indeed invalid HTML. How an invalid attribute is handled . Thus, The webview neither before nor after the commit reflected the standard correctly. A possible solution is: Note that the code above omits elements, because I think it's not worth handling them.
Change:
IFS=':' read -rA ADDR <<< "$VSCODE_ENV_APPEND" for ITEM in "${ADDR[@]}"; do VARNAME="$(echo ${ITEM%%=*})" <del> export $VARNAME="${(P)VARNAME}$(echo -e {ITEM#*=})" </del> <ins> export $VARNAME="${(P)VARNAME}$(echo -e ${ITEM#*=})" </ins> done unset VSCODE_ENV_APPEND fi

Discussion:
Testing seems to fail on zsh shell: !
Moving this to August same as the other issue:
Let me know if we're unable to fix this in time, in which case I'll stop prepending for zsh in Python extension.
Looking into it now
Change:
top: 0px; } <del> .monaco-workbench .part.editor>.content .getting-started-category .codicon::before { </del> <ins> .monaco-workbench .part.editor>.content .getting-started-category .codicon-star-full::before { </ins> vertical-align: middle; }

Discussion:
<!-- 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. --<!-- 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.61.0-insider OS Version: macOS 11.5.2 The tiles showcasing the welcome walkthrough contributions look like they should be vertically centering the content. As of now the icon and close icon are aligned to the bottom and top, respectively. <img width="504" alt="CleanShot 2021-09-24 at 10 49 20 src="https://user-"Icon aligned to the bottom: <img width="126" alt="CleanShot 2021-09-24 at 10 53 40 src="https://user-"Remove icon aligned to the top: <img width="196" alt="CleanShot 2021-09-24 at 10 53 52 src="https://user-"