jiebi/CodeConvo huggingface dataset:
Code change:
"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",

Related discussion:
text: Type: <bBug</bIn the most recent insiders version, audio cues no longer play. I ensured that the audio cues I expect are enabled (e.g. error) and entered the following json as an example: I ensured that the error was reported when moving through errors with f8, yet the cue doesn't play when I come across the line with up/down arrow keys VS Code version: Code - Insiders 1.71.0-insider (, 2022-08-05T07:36:58.753Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No <!-- generated by issue reporter --
cc
We didn't touch anything there the last months, maybe it is caused by an electron update. Will investigate for the next release.
I can reproduce this. Easy repros steps: 1 list audio cues command cues do not produce sound Works fine on latest stable. Does not work on Insiders. fyi since most likely caused by Electron update (thus adding label). Maybe our future planned ffmpeg change will fix this? thanks a lot for reporting this, and sorry about this breakage.
You're welcome, I'm running insiders for a reason Looking forward to a fix.
Let me also assign since we will now support would you like that all our audio cues are in format? If yes, would you like me to reach out to our sound designer for this? Thanks
can you track the conversion in a separate issue, this particular issue is a regression with the ffmpeg build shipped with internal builds. There was a recent build architecture change and it impacted this. I would like to close this issue as part of the next Electron version update :)
makes sense, thanks! There is actually already this one which we can use for the conversion
The same problem using code-insiders into a fedora workstation 36.
It is working again with orca.
lovely, thanks for confirming. Adding verified label.
For me it also works like a charm on Windows.
For some reason I can't explain, this issue seems to have returned on my fedora workstation. No sound is played when I move the cursor to lines that contain breakpoints, errors and etc. Version: 1.71.0-insider Commit:
Confirmed on Windows. Could tests for this be somehow?
Code change:
"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",

Related discussion:
text: Sorry for the regression, but this is a temporary expected breakage because we are updating our supported audio formats , audio cues will be updated to new format this iteration as part of /cc
Sorry about that We just pushed a fix, and the VS Code insiders from tomorrow will have the fix.
Thanks Given this feature turns out to be pretty important for us visually impaired users, would it be possible to create a system test for this? I assume it should be possible to throw a audio cue at FFMPEG and make it fail if the sound doesn't play?
that's a good idea. However I leave this up to since he is driving this from engineering and would have better ideas how we could test it exactly.
We would need a way to ask the OS if an application played some sound.
It works again, at least on my environment. Thanks.
awesome, thanks for letting us know.
I can confirm that it works here as well. Hopefully it stays that way
Code change:
"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",

Related discussion:
text: <!-- 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.
Code change:
"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",

Related discussion:
text: 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 .
Code change:
"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",

Related discussion:
text: 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!
Code change:
"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",

Related discussion:
text: 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
Code change:
{ link: 'foo 339', prefix: undefined, suffix: ' 339', hasRow: true, hasCol: false }, { link: 'foo 339:12', prefix: undefined, suffix: ' 339:12', hasRow: true, hasCol: true }, { link: 'foo 339.12', prefix: undefined, suffix: ' 339.12', hasRow: true, hasCol: true }, <ins> { link: 'foo 339.12-14', prefix: undefined, suffix: ' 339.12-14', hasRow: true, hasCol: true, hasRowEnd: false, hasColEnd: true }, { link: 'foo 339.12-341.14', prefix: undefined, suffix: ' 339.12-341.14', hasRow: true, hasCol: true, hasRowEnd: true, hasColEnd: true }, </ins> // Double quotes { link: '"foo",339', prefix: '"', suffix: '",339', hasRow: true, hasCol: false },

Related discussion:
text: The : This doesn't currently work in VSCode. It does support a very wide range of formats and I don't recall ever seeing this format before (even from GNU tools) so I suspect nobody else uses it. Nonetheless it's easy to add support in VSCode. See
Doesn't seem to work, see <img width="825" alt="Screenshot 2023-08-29 at 14 41 05" src=""
The PR intentionally left that out: But it should be easy to add so will leave this open.
Code change:
// Do not trigger state if current state is manual and incoming state is automatic if (!isManualToAutoTransition) { this.setState(newState); <ins> } else { // Reset the new state after getting code actions back. setTimeout(() => { this.setState(newState); }, 500); </ins> } }, undefined); this._codeActionOracle.value.trigger({ type: CodeActionTriggerType.Auto, triggerAction: CodeActionTriggerSource.Default });

Related discussion:
text: Under some circumstances, the Code Action button won't go away and will still run its assign command (incorrectly) Steps to Reproduce: an error with 'Quick Fix' available ! the cursor on the same line and press to bring up the quickfix ! to cancel ! the code action button ! the button again ! again ! ! at step 4. the button should disappear, but it does not I found this bug while adding Code Actions to my personal extension VS Code Version: 1.88.1 OS Version: Windows 11
Code change:
{ "name": "code-oss-dev", "version": "1.88.0", <del> "distro": "37f287ed9d23ce03684ef672b6b295c13afc9fa5", </del> <ins> "distro": "340432a8308f66007779ec2133ee39e6995006cb", </ins> "author": { "name": "Microsoft Corporation" },

Related discussion:
text: Perhaps we forgot to update the distro json files (for stable, insiders, oss)?
!
it was to distro weeks and many commits ago. I'm not seeing the same error, even when that API is used in insiders/pre-release. - Do you know if I forgot a step for enabling this?
I think there's a typo, in of distro you have `"NotebookCellExecution", and in jupyter extension you have , notice the casing of the first char
Code change:
import { IKeyboardEvent } from 'vs/base/browser/keyboardEvent'; import { KeyCode } from 'vs/base/common/keyCodes'; <del> import { Disposable, toDisposable } from 'vs/base/common/lifecycle'; </del> <ins> import { Disposable, DisposableStore, toDisposable } from 'vs/base/common/lifecycle'; </ins> import { URI } from 'vs/base/common/uri'; import { IEditorConstructionOptions } from 'vs/editor/browser/config/editorConfiguration'; import { EditorExtensionsRegistry } from 'vs/editor/browser/editorExtensions';

Related discussion:
text: It doesn't matter in this case, but note that you collect all the keyListener disposables in the store of the AccessibleView class (even if you dispose them in , but the disposable is still in the disposableStore). This can lead to memory leaks. I can really recommend to compose components according to their life times. I think here the lifetime of the rendered content is owned by the caller of (the caller is supposed to call on the result). So the disposable returned by should be owned by whatever you return in . I suggest to create a DisposableStore in render, push the key listener to it once the text model resolves and return the disposable store at the end of render (also add the to the store). Also, note that the getTextModel promise can resolve after the caller called dispose. Originally posted by in
Code change:
background-size: 16px; } <del> @keyframes shift { 0% { transform: translateX(0px); } 33%{ transform: translateX(0.5px); } 66% { transform: translateX(-0.5px); } } .monaco-toolbar.config .monaco-action-bar .action-item { animation-duration: 1.2s; animation-iteration-count: infinite; animation-name: shift; } .monaco-toolbar.config .monaco-action-bar .action-item:nth-child(odd) { animation-delay: 0.6s; } </del> .monaco-dropdown-with-default { display: flex !important; flex-direction: row;

Related discussion:
text: I recently noticed an animation to indicate toolbar actions can be changed: ! This seems to be inspired by Safari toolbar when you edit it: ! I am seeing a few issues with our approach: we allow to change visibility of actions in a lot of places (activity bar, status bar) where currently there is no such animation in Safari to get into this mode, the user explicitly picks an action "Customize Toolbar" while for us it starts on right click already in Safari you can actually grab an action and move it, I even think they only animate the action to make that more obvious (not so much the fact that you can hide the action) I would vote for not having the animation until we can support what Safari does including to drag and reorder actions. I think the menu makes it already clear what the right click gesture allows you to do: <img width="299" alt="image" src="https://user-"
Yes, thanks, this feels very strange to me. I don't think animating the whole menubar make sense when you are only operating on a single item.
How about beginning a right-click menu with an inactive entry that acts as a header? Something like "Button Visibility". It would also act as a protection against accidental hiding, since I can imagine some folk inadvertently pressing right button down, moving the mouse a few pixels right, releasing the button and seeing vanish the button they intended to actuate. Especially on Linux where there's a longstanding issue about this happening on context menus at certain Zoom levels and certain places on the screen.
related/motivation
Well, strictly speaking you operate on the whole menu because you also have toggle actions for all its entries. I like that direction. We already do something similar to right click the overflow item. You cannot hide that but you get a disabled "Hide" entry for consistency. On the flip side it is bogus use of menu items as "headers" <img width="340" alt="Screenshot 2022-09-29 at 08 23 30" src="https://user-"Overall the motivation for same kind of animation is mostly the . Left and right click show a context menu which do very different things but look very similar
Any scope for changing the button icon when in this edit mode? Maybe to pencil or gearwheel.
Note that animations like this look pretty terrible on standard DPI monitors due to the blurriness.
Code change:
background-size: 16px; } <del> @keyframes shift { 0% { transform: translateX(0px); } 33%{ transform: translateX(0.5px); } 66% { transform: translateX(-0.5px); } } .monaco-toolbar.config .monaco-action-bar .action-item { animation-duration: 1.2s; animation-iteration-count: infinite; animation-name: shift; } .monaco-toolbar.config .monaco-action-bar .action-item:nth-child(odd) { animation-delay: 0.6s; } </del> .monaco-dropdown-with-default { display: flex !important; flex-direction: row;

Related discussion:
text: It also removes sub-pixel anti-aliasing which makes it look even more different to non-animating. ! Regular: ! Animating: !
is that specific to this animation or something you notice with animations in general? Like the sync-spinner or the language status wiggle?
I also think the spinner looks pretty bad, though it's less noticeable than this I don't think I've noticed this, but any animation like these should have this problem. You can notice it when websites use animations as well, the shift from animated to non-animated is often jarring.
Or even spinning gearwheel
Can you please file a dedicated issue? There is a bunch of places that use CSS animations and if there is a flaw with that we should look at it holistically Created to disable the animation for now. Let's take time in October to revisit this. Lets discuss (1) if this is really needed and (2) if we should align other hide-able items (consistency is key)
created with a lot of details
Code change:
registerThemingParticipant((theme, collector) => { let editorGuideColor = theme.getColor(editorIndentGuides); if (editorGuideColor) { <del> collector.addRule(`.monaco-editor .lines-content .cigr { background-color: ${editorGuideColor}; }`); </del> <ins> collector.addRule(`.monaco-editor .lines-content .cigr { --box-shadow-color: ${editorGuideColor}; }`); </ins> } });

Related discussion:
text: The rulers and indent guides do not display well on high pixel density displays VSCode Version: Version 1.21.0 (1.21.0) OS Version: macOS Sierra 10.12.6 (16G1212) Steps to Reproduce: out editor Does this issue occur when all extensions are disabled?: Yes Example !
Code change:
const disposable = new DisposableStore(); const notebook = workingCopy.model.notebookModel; <ins> // get initial cursor positions const activeCellEditor = getActiveCellCodeEditor(this.editorService); let selections; if (activeCellEditor) { selections = activeCellEditor.getSelections() ?? []; } </ins> try { const allCellEdits = await Promise.all(notebook.cells.map(async (cell) => { if (cell.cellKind !== CellKind.Code) {

Related discussion:
text: Re , I was editing the endgame notebook in VS Code repo but it keeps moving the cursor to the next line, which breaks typing. It's very likely an issue with these two settings combined "files.autoSave": "afterDelay" We seems to have the same issue for files in text editor but untitled file doesn't suffer from this as it can't be auto saved. I wonder if we should have some special treatment for notebook cells, as it's very usual to create new cells, which are always empty at the beginning, typing in the first line is making it almost impossible. Maybe we could keep the cursor position for this scenario.
Code change:
isInMemory(): boolean { return this.options.hint === StorageHint.STORAGE_IN_MEMORY; } <del> override dispose(): void { this.flushDelayer.dispose(); super.dispose(); } </del> } export class InMemoryStorageDatabase implements IStorageDatabase {

Related discussion:
text: When running unit tests:
Similar problem in
This is not coming from those tests, the ugly part is these errors just report async. I found the following tests to be the underlying cause: The best is to run and add a breakpoint here:
I think I may have found a central fix...
Code change:
context.subscriptions.push(cleaner); } <del> // Update new file contribution vscode.extensions.onDidChange(() => { vscode.commands.executeCommand('setContext', 'jupyterEnabled', vscode.extensions.getExtension('ms-toolsai.jupyter')); }); vscode.commands.executeCommand('setContext', 'jupyterEnabled', vscode.extensions.getExtension('ms-toolsai.jupyter')); </del> return { get dropCustomMetadata() { return !useCustomPropertyInMetadata();

Related discussion:
text: Steps to Reproduce: a notebook with the jupyter extension installed context keys the context key contains the entire contents of the file for that extension:
Code change:
cacheHitVar: NODE_MODULES_RESTORED displayName: Restore node_modules cache <del> - script: tar -xvzf .build/node_modules_cache/cache.tgz </del> <ins> - script: tar -xzf .build/node_modules_cache/cache.tgz </ins> condition: and(succeeded(), eq(variables.NODE_MODULES_RESTORED, 'true')) displayName: Extract node_modules cache

Related discussion:
text: A similar error has appeared for other Azure Pipelines tasks
Odd: one is about extracting first one shows no error at all (copy paste mistake?) second one is about creating a zip
This might actually be a bug on AZDO:
And we might be hitting it due to logging every single file. Let's stop doing that.
I reran the failure for the first one which is why it no longer shows an error here's the precise link to the failure
Thanks!