jiebi/CodeConvo huggingface dataset:
Change:
function focusFirstFocusableInCell(cellId: string) { const cellOutputContainer = document.getElementById(cellId); if (cellOutputContainer) { <ins> if (cellOutputContainer.contains(document.activeElement)) { return; } </ins> const focusableElement = cellOutputContainer.querySelector('[tabindex="0"], [href], button, input, option, select, textarea') as HTMLElement | null; focusableElement?.focus(); }

Discussion:
<!-- Please search existing issues to avoid creating duplicates. --- VS Code version: 1.68.0 (Universal) / 1.69.0-insider (Universal) Jupyter Extension version (available under the Extensions sidebar): v2022.6. Python Extension version (available under the Extensions sidebar): v2022.8.0 OS (Windows Linux distro) and version: macOS Monterey version 12.4 Python and/or Anaconda version: Python 3.10.4 Type of virtual environment used (N/A ...): - Jupyter server running: Local Ipywidgets Dropdown selector should stay open until the user click on the desired selection. When combining several types of selector (e.g. a slider and a dropdown), the Dropdown menu flashes briefly and doesn't stay open, so the selection is impossible. This issue seems to appear only for a combination of selectors (a dropdown alone works properly). This issue appears in VSCode but not in Jupyter Lab. !
Sorry you are running into this issue and thanks for filing this issue. I can repro this issue at my end, will look into this.
Note for Team: I can repro this for a lot of widgets that use dropdown and textboxes/sliders. Seems like a pretty bad regression, basically I'm unable to select anything from the dropdown. I've tested this with VS Code Version 1.66 and older versions of Jupyter along with the latest dev version of VS Code Jupyter and it works as expected. Seems like a regression in VS Code.
From Don's analysis this looks to have regressed recently.
While waiting for a resolution to this issue, a temporary workaround (and additional info to the issue that is not captured in the above posts) if you are only working with one dropdown menu is to place it first of all widgets. It seems the first widget will constantly get focus, which is what causes the dropdown menu to instantly close if it's placed after any other widgets. If the first widget is the dropdown menu, it will still sometimes flash, but for the most part work. If you have several dropdown menus this will only work for the first widget.
thanks ras, that worked! Also nothing that this is still an ongoing issue with the june update
I think this should have the 'candidate' label. It is assigned to the June 2022 Recovery 2 milestone but lacks the label to make it appear on the candidate query results.
Change:
keys.forEach(key => assert(typeof definitions[key] === 'string', `Missing value for '${key}' in Inno Setup package step`)); const defs = keys.map(key => `/d${key}=${definitions[key]}`); <del> const args = [iss].concat(defs); </del> <ins> const args = [ iss, ...defs, `/sesrp=powershell.exe -ExecutionPolicy bypass ${signPS1} $f` ]; </ins> cp.spawn(innoSetupPath, args, { stdio: ['ignore', 'inherit', 'inherit'] }) .on('error', cb)

Discussion:
is from an unknown publisher
!
Oh it really seems like you can't uninstall it... Not good.
Related to

Unlike the VS Code installer for Windows, the VS Code uninstaller for Windows is not signed. You can fix this by using the directive in your Inno Setup script. See For dual signing it's easiest to use Inno Setup 5.5.8 instead of 5.5.6 as you currently use: 5.5.8 allows you to have two SignTool directives, one for the sha-1 signing and another for the sha-256 signing.
To keep the number of issues in our inbox on a manageable level, we're closing issues that have been on the backlog for a long time but haven't gained traction: We look at the number of votes the issue has received and the number of duplicates issues filed. Thanks for your understanding. Happy coding!
Change:
code { font-size: 1em; <ins> font-family: var(--vscode-editor-font-family); </ins> } pre code { <del> font-family: var(--vscode-editor-font-family); </del> line-height: 1.357em; white-space: pre-wrap; }

Discussion:
Issue Type: <bBug</bSteps to Reproduce:  in a Markdown cell in Jupyter notebook. The monospace font used in Jupyter notebook () Markdown code blocks is not consistent with in the settings. ! This does not occur in a seperate Markdown () file. ! VS Code version: Code 1.66.0 (, 2022-03-30T05:50:14.623Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --
Change:
import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; import { ILogService } from 'vs/platform/log/common/log'; import { INotificationService } from 'vs/platform/notification/common/notification'; <del> import { IShellLaunchConfig, TerminalLocation, TerminalSettingId, WaitOnExitValue } from 'vs/platform/terminal/common/terminal'; </del> <ins> import { IShellLaunchConfig, TerminalSettingId, WaitOnExitValue } from 'vs/platform/terminal/common/terminal'; </ins> import { formatMessageForTerminal } from 'vs/platform/terminal/common/terminalStrings'; import { ThemeIcon } from 'vs/platform/theme/common/themeService'; import { IViewDescriptorService, IViewsService, ViewContainerLocation } from 'vs/workbench/common/views';

Discussion:
. a folder and add this task: that task The task runs, but there is an error that shows in a notification:
shouldn't be getting used in the stack trace
when I set default location to editor and run the build task, terminals are appearing in the panel. is that by design ?
Currently that is by design as tasks + terminals in the editor don't work.
that might just be a matter of removing location here?
I the location to work around the issue:
is here when the terminal is in the editor, so we must be listening to somewhere in terminal editor code and disposing of the terminal !
yep, here
active instance does get updated for me, but could repro an issue where wasn't respected - fix for that incoming https://user-
Change:
resolved "https://registry.yarnpkg.com/wrappy/-/wrappy-1.0.2.tgz#b5243d8f3ec1aa35f1364605bc0d1036e30ab69f" integrity sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8= <del> xterm-addon-canvas@0.3.0-beta.33: version "0.3.0-beta.33" resolved "https://registry.yarnpkg.com/xterm-addon-canvas/-/xterm-addon-canvas-0.3.0-beta.33.tgz#5f6f673df9f8e9ea82d980a93adb8f0fe1ec5f0f" integrity sha512-nKZ3ieluM6GthY4LCOMF2uWtrHASz6efm9pekgeEmLz5DOINyCBSm2SsPp3s9edLTWMGHp8oe+diSk/+sz65cA== </del> <ins> xterm-addon-canvas@0.3.0-beta.35: version "0.3.0-beta.35" resolved "https://registry.yarnpkg.com/xterm-addon-canvas/-/xterm-addon-canvas-0.3.0-beta.35.tgz#2f85f9df9b109d51a8ce08a6023db747f4d060d5" integrity sha512-chk/+FaUPEAC33Mt6PDLbUWlzDCCoXBWJvKykMfhZF0vCm8GqpJc3z6R9jdcZcNCPUhmmv5psRTYun6oy5TvBQ== </ins> xterm-addon-search@0.11.0-beta.7: version "0.11.0-beta.7"

Discussion:
Testing Code insiders, set how the inactive selection colour is stronger than the active selection colour I can only reproduce this with "canvas", all other gpu acceleration options work fine. Terminal focused ! Terminal not focused !
Upstream:
Change:
outputWordWrap: this.options.outputWordWrap }; const preloadScript = preloadsScriptStr( <del> this.options, </del> <ins> { ...this.options, tokenizationCss: getTokenizationCss(), }, </ins> { dragAndDropEnabled: this.options.dragAndDropEnabled }, renderOptions, renderersData,

Discussion:
<!-- Please search existing issues to avoid creating duplicates. --- VS Code version: 1.79.1 Jupyter Extension version: 2023.5. Python Extension version: 2023.10.1 OS and version: Windows 11 Home Version 22H2, build .1778 If I change the theme after entering code in a Markdown cell, the code highlighting should change accordingly. Light theme: <img width="51" alt="image" src=""Dark theme: <img width="52" alt="image" src=""The code highlighting in Markdown cells does not change according to the theme. Light theme: <img width="44" alt="image" src=""Dark theme: <img width="48" alt="image" src=""an .ipynb file. a Markdown cell. some text formatted as code, e.g. python a = 5 ` Shift + Enter to render cell. theme (for example, if code was entered when using Light Modern, switch to Dark Modern). The code highlighting in the Markdown cell does not change and is now difficult to read.
Change:
version "2.5.1" resolved "https://registry.yarnpkg.com/nan/-/nan-2.5.1.tgz#d5b01691253326a97a2bbee9e61c55d8d60351e2" <del> nan@^2.0.0, nan@^2.6.2: version "2.6.2" resolved "https://registry.yarnpkg.com/nan/-/nan-2.6.2.tgz#e4ff34e6c95fdfb5aecc08de6596f43605a7db45" </del> <ins> nan@^2.0.0: version "2.9.2" resolved "https://registry.yarnpkg.com/nan/-/nan-2.9.2.tgz#f564d75f5f8f36a6d9456cca7a6c4fe488ab7866" </ins> nan@^2.0.9, nan@^2.3.0: version "2.4.0"

Discussion:
VSCode Version: 1.17.0 () OS Version: Ubuntu 16.04 LTS Steps to Reproduce: "files.useExperimentalFileWatcher": true and close VS Code a symlink to root directory (must be an absolute link, not relative!): directory containing that symlink in VS Code: processes - one of vs code processes takes high CPU Reproduces without extensions: Yes See also:
Just noticed the same thing on osx...
Updating issue with: vs code version 1.17.0 reproduces without extensions ! Also, I found memory usage increasing over time...
Same issue here vs code version 1.17.2 Even after closing the VsCode the Code Helpers is still running with 100% CPU usage.
Reported upstream
Upstream PR
The original PR was closed so I opened one which was merged , just need a release to pull this in.
I have vscode 1.19.2 on Ubuntu. The various nodemodules directories have symbolic links point to each other that form the circular links. The nodemodules is set excluded in "files.watcherExclude". After vscode is started, it uses 100% CPU and memory usage increased dramatically and soon reached the max memory and hang the system. This problem happens whatever useExperimentalFileWatcher is set true or false. The ps shows the problem code process has parameter '--type=watcherService". Attached gdb to the process, it shows the watcher follows through the circular symbolic links in circular. Set "search.followSymlinks": false has no effect,. So this problem still happens in 1.19.2 even with all the right settings in place.
is it possible/easy to patch VS Code to stop this behaviour while waiting for it to hit a release? I have a workspace that causes a 20GB VM to exhaust its memory in about 15 mins because of circular symlinks (it uses lerna).
yeah I'll fork the module to get this in, was hoping I wouldn't need to.
what's the expected behavior after the change? I'm still seeing high CPU on today's insiders version on Ubuntu ! on Mac
the fix is specific to Linux only when you have experimental file watcher set to true in settings (or you have a multi-root workspace open).
If you have this issue, it's not just high CPU usage - your memory will be exhausted within minutes.

With a workspace with circular symlinks in it (it uses lerna and has circular dependencies), I was seeing 20GB of RAM get sucked up in about 15 minutes. Insiders has had the fix for a while now.
thanks, I'll mark as verified since you saw it before :+1:
Change:
import DOM = require('vs/base/browser/dom'); import URI from 'vs/base/common/uri'; import errors = require('vs/base/common/errors'); <ins> import {RunOnceScheduler} from 'vs/base/common/async'; </ins> import {isMacintosh} from 'vs/base/common/platform'; import {IWorkbenchEditorService} from 'vs/workbench/services/editor/common/editorService'; import {IContextMenuService} from 'vs/platform/contextview/browser/contextView';

Discussion:
For: scoped keybinding service scoped progress service For the title area and the editor itself. This requires a common parent (or the editor-container itself) to be reparented instead of the editor moving around. Enables more scenarios around menu and command contributions for contexts.
I merged this to master: title container, editor container, progress bar widget and the instantiation service are now within a new container that gets reparented when a) you move an editor around or b) you close editor group LEFT when LEFT | RIGHT exist and RIGHT becomes LEFT as well as for when you have 3 editors open and you close the left or center group. Is there a way to verify this works for the scenario you disabled late before we finished June milestone? I remember you reverted a commit and I am not sure if this can be now reverted back again. !
I can verify
LGTM - will push the revert revert commit
Verified via
Change:
public static readonly ID = 'editor.contrib.unusualLineTerminatorsDetector'; private _config: 'auto' | 'off' | 'prompt'; <ins> private _isPresentingDialog: boolean = false; </ins> constructor( private readonly _editor: ICodeEditor,

Discussion:
Issue Type: <bBug</bI had a file with unusual line endings in it, and this happened: the dialog kept reappearing after pressing 'ignore' until i finally relented. When I tried to create a new file with weird line endings it seemed to work, maybe since I had the file opened while the file was being generated, every time the file changed the dialog was re-enqueued even though it was already open? VS Code version: Code 1.66.2 (Universal) (, 2022-04-11T07:49:20.994Z) OS version: Darwin arm64 21.1.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ astro-vscode0.16.0 vscode-graphql0.4.4 vscode-docker1.22.0 svelte-vscode105.16.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
could you post some steps to verify?
I could not reproduce this myself, I did the change by realizing that the code showing the dialog is re-entrant. Could you please verify the fix using our
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
I tried adding to the end of files and got the dialog, but I couldn't get the dialog to keep showing up on Stable.
Verified by code review
unfortunately it was a one-off conversion script from an old system that caused the issue which I don't have any longer, so I'm not sure about the exact steps to reproduce it! edit: oops wrong account, i'm threecreepio. :D
Change:
if (executingCells[0]) { const cell = context.notebookEditor.getCellByHandle(executingCells[0].cellHandle); if (cell) { <del> context.notebookEditor.revealInCenter(cell); </del> <ins> context.notebookEditor.focusNotebookCell(cell, 'container'); </ins> } } }

Discussion:
Testing Set to Resize the window so that it's just big enough for the labels to appear Run a cell Notice that the labels in the toolbar disappeared I don't know what the best solution for this would be, if there's any Since a new icon + label are to the toolbar when running a cell, this issue is bound to happen for window dimensions that straddle the line between labels being displayed and hidden (and that's not even considering translations). https://user-
Basically by design, a shorter label for "Go to Running Cell" would help. Would just "Go To" (with the full label in tooltip) and with the spinning icon be clear? Any other ideas to mitigate it
I think the spinning icon is a good enough indicator. Even if we address the issue with "Go To", it might happen in languages with a longer translated label.
Are you saying the button shouldn't have a label in the toolbar?
Oh no, I meant to say that the current solution is good enough.
Change:
import * as TaskConfig from '../common/taskConfiguration'; import { TerminalTaskSystem } from './terminalTaskSystem'; <del> import { IQuickInputService, IQuickPickItem, QuickPickInput } from 'vs/platform/quickinput/common/quickInput'; </del> <ins> import { IQuickInputService, IQuickPickItem, QuickPickInput, IQuickPick } from 'vs/platform/quickinput/common/quickInput'; </ins> import { TaskDefinitionRegistry } from 'vs/workbench/contrib/tasks/common/taskDefinitionRegistry'; import { IContextKey, IContextKeyService } from 'vs/platform/contextkey/common/contextkey';

Discussion:
We have a temporary fix for the release for but we need to do something better long term.
while working on quick access for tasks I noticed that we seem to be having 2 pickers for the same thing (?): Task quick open: ! "Run Task" picker: ! Is that intentional? Should the one be merged into the other?
Yes, they do not share much code :( as part of improving the quick pick I will converge them.
sounds good, please only change  and leave the other one because I plan to delete those old ones soon.
Change:
<meta charset="UTF-8"> <meta http-equiv="Content-Security-Policy" <del> content="default-src 'none'; script-src 'sha256-j+I5FRqQBE2aQY6H/U/pjZI3buJy36yZ/upZTKZov3c=' 'self'; frame-src 'self'; style-src 'unsafe-inline';"> </del> <ins> content="default-src 'none'; script-src 'sha256-JLx+LG3LboPnZ7e91Q6dkbi50CHab+JYYk7+m6GKJxI=' 'self'; frame-src 'self'; style-src 'unsafe-inline';"> </ins> <!-- Disable pinch zooming --> <meta name="viewport"

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/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.69.2 OS Version: Steps to Reproduce: have developed an extension, the extension has some webview page, then I install on VSCodeit is ok, the webview is shown; I run it on code-server, my ip is 192.168.88.212, then I input http://127.0.0.1:3000, it is also ok, the webview page is shown; I input 192.168.88.212:3000, the webview page is not shown, and the error is "Can't compute sha-256" you help to fix it ? thank you very much
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.71.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Thank you for reply very much, I have download the vscode-1.71.2, and then I install and run, the problem still exits, Can you help me?
Do other webviews work, such as the built-in markdown preview or release notes page?
It also not works
I investigated this a determined this is a limitation of how our webviews are implemented. To use them, the editor needs to be running in a This includes but would not include an ip such as . That is why works. This feature would also for other ips if you can use instead of Closing since this is by-designed, although I've a more clear error message in
Change:
DOM.hide(this.editorPart); DOM.hide(this.templateData.collapsedPart); this.markdownAccessibilityContainer.ariaHidden = 'false'; <del> this.templateData.container.classList.toggle('collapsed', false); </del> this.templateData.container.classList.toggle('markdown-cell-edit-mode', false); this.renderedEditors.delete(this.viewCell);

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/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.59-Insider OS Version: Windows 10 Steps to Reproduce: a notebook a cell cells are rotated 270 degrees. Seems to be because we use the 'collapsed' classname for cell collapse, and loads a stylesheet which applies to the classname. This stylesheet is not loaded in desktop VS Code so the problem seems to only impact Codespaces This is particularly unfortunate for the interactive window because all code cell inputs are collapsed by default, but it also impacts any collapsed cell in native notebooks all up. !
I filed this a long time ago, but this is pretty bad, I will just change the styles to work around it in the meantime
fix proposal from
Change:
const timeout = window.setTimeout(() => this.remove(status), duration); this._statusTimeouts.set(status.id, timeout); } <ins> const existingStatus = this._statuses.get(status.id); if (existingStatus && existingStatus !== status) { this._onDidRemoveStatus.fire(existingStatus); this._statuses.delete(existingStatus.id); } </ins> if (!this._statuses.has(status.id)) { const oldPrimary = this.primary; this._statuses.set(status.id, status);

Discussion:
Just saw , this goes against the design. It's meant to only add the status if it doesn't already exist, if the status changed then it should use a different id and/or remove the old status first.
I'm not clear on the solution. There're a limited number of Terminal Status IDs: In this case status ID hasn't changed, it's still , only the description which comes with it has updated.
working on it, I'll send a PR to you in a bit
Validate still doesn't happen.
Change:
builtin printf "x1b]633;P;IsWindows=Truex07" fi <ins> # Allow verifying $BASH_COMMAND doesn't have aliases resolved via history when the right HISTCONTROL # configuration is used if [[ "$HISTCONTROL" =~ .*(erasedups|ignoreboth|ignoredups).* ]]; then __vsc_history_verify=0 else __vsc_history_verify=1 fi </ins> __vsc_initialized=0 __vsc_original_PS1="$PS1" __vsc_original_PS2="$PS2"

Discussion:
Testing In Remote-WSL + bash + subshell, if I run and then use the command decoration to rerun the command, it instead runs . !
This is also the reason may be replaced by ; we're sending the alias resolved command line instead of the raw command line as input.
We should also verify this doesn't happen with aliases in zsh
fyi verifier, reproduces in normal in a non-subshell
to reproduce: in a terminal to see the ones you've defined the part to the left of the command decoration menu, the command's alias (part to the right of ) is the input
it does not
the alias value is also displayed in the quickpick atm
I thought of an even better idea to what we talked about, we could use the old history method to supplement our current better method; if there are no problematic histcontrol settings and the latest history command changed between precious and now, assume it was an alias and use that?
could you verify this one when you get a chance?
still seems to repro in Remote-WSL ! Version: 1.71.0-insider (user setup) Commit: Date: 2022-08-23T10:56:12.685Z Electron: 19.0.12 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
Does show anything? My Ubuntu wsl shows in which case we cannot use that history method which is a known edge case that I don't think we can handle currently and is not worth tracking imo.
Yeah the output is . Is there a value I can change that to which would allow me to verify the fix?
it can be set to the empty string or - set this in your which should run before shell integration
<img width="278" alt="image" src="https://user-"

See comments in Workaround for anyone hitting this is to set to one of , , in your .
See earlier report on
/duplicate