jiebi/CodeConvo huggingface dataset:
An information disclosure vulnerability exists in VS Code 1.71 and earlier versions. If an attacker is able to run arbitrary scripts inside of a webview (either created by extension or by core VS Code), the attacker could bypass the local resource roots check to read arbitrary files on the user's system The fix is available starting with VS Code 1.71.1. The mitigates this attack by performing input validation on the URL pointing to the repository to be cloned. Only use webviews from extensions that follow proper security measures to block script injection Do not disable VS Code's default security measures in the built-in markdown preview The patch for this can be found at An advisory for this can be found at MSRC details for this can be found at
Hi, just curious about this: The description of the vulnerability ends mid-sentence. I see the same phrasing on the GHSA advisory as well: Can it be revised to be clearer what is the nature of the vulnerability? (And of course: Thanks for finding and fixing it, and for making these advisories! Transparency and security are appreciated!)
Updated
Should the references to 1.71 in fact be 1.72?
VSCode Version: Code - Insiders 1.12.0-insider (, 2017-04-13T06:10:58.128Z) OS Version: Windows_NT ia32 6.1.7601 Extensions: the listing exceeds the lower minimum of browsers' URL characters limit Steps to Reproduce: any file and try to horizontal scroll either via mouse wheel or shift scroll.
Hello i'm still experiencing this issue , I've noticed a separate issue was closed for Ubuntu users, but still noticing this with Windows.
This seems to be fixed in the latest release.
correction, this issue still exists.
/cc I'm seeing this issue again as well, on my Ubuntu work machine and on Windows: VSCode Version: Code - Insiders 1.12.0-insider (, 2017-04-21T06:12:00.370Z) OS Version: Windows_NT ia32 10.0. Extensions: ;
Some more info: shift+mouse wheel does not work, however when I use the trackpad and two finger swipe horizontally it works fine. Unplugging and plugging in the mouse again didn't fix it.
Hmm the trackpad usually is for forward and back commands. I can confirm this is the same case for me. I'm wondering if electron has switched the forward and back commands for the horizontal scrolling. Because in my mouse settings if I set the horizontal scroll will to page forward and backward it works perfectly. But I shouldn't have to do that.
I tried to reproduce and failed with my setup (Windows 10 and Windows 7 on macOS running in Parallels). Here is what I try: shift-scrolling in the editor wheel-left/right in the editor ! Are you doing something different? Does it reproduce when you run with blank settings?
I tried to reload vscode insiders without any settings, and i'm still having the same experience.
One other note, I have mac os sierra at my home workstation and everything works perfectly there. It seems to be Windows specific. I'm running Windows 7
Here are errors and warnings upon restarting insiders without typing anything. I wonder if this has anything to do with it.
I assume those warnings would go away when you run code . I would not assume however that this would help you for this issue, but worth a try anyway.
I wonder if we could do a little experiment.
Can you: download run it from the window that opens make it small enough that horizontal scrollbars appear see if you can scroll ! If so, this would point to a general problem with our UI framework (electron) and we should report it there.
seems to be this line that's throwing an error which may be causing the scroll to not work.
I would think that is unrelated, but please follow my steps to find out more.
I downloaded () on the Linux machine that I can reproduce it on and I can scroll just fine. ! Note that after this gif I updated to latest and it still doesn't work on:
Sorry I didn't see your message until just now. Yes it scrolls fine. On Mon, Apr 24, 2017, 10:31 AM Daniel Imms <:
need your help here for more debugging. First thing that comes to my mind is to add a breakpoint into  to see if this is even triggered when scrolling horizontally?
it's hit, but is set, not as I would expect. ! is set though: ! Are we meant to handle manually?
any chance you could debug stable to verify that e.deltaX is set? Is there any other property that has an increasing value? /cc if you have any clues on this Looking for chrome issues I stumbled upon:
Fixed via
Thank you guys, very much appreciated. Have realized over the last few days just how much I depend on horizontal scrolling.
As i'm not familiar with the insiders release pattern, any idea when we can expect this to come down the pipeline ?
should be in tomorrow's Insiders build
Thank you Daniel Imms <:
In order to create custom keybindings to toggle focus between the editor and something such as the terminal panel, a command to focus the active/most recently used editor group needs to be . I believe this is the best that can be accomplished currently: Focuses the first group, meaning if the second or third editor groups were focused this would feel wrong: Or this which focused the most recently used editor group but opens the last editor/file in the group: Some context on request:
isn't that as easy as providing a global command that just puts focus into the active editor? E.g. ? PR welcome if you wanna give it a try.
yes, I expect it to be pretty easy.
got a better name than ?
works for me
Testing I found "Find in Cell Selection" confusing label for the button given it is to find in selected cells. Does it make sense? Would "Find in Selected Cells" be a bit easier? !
Yeah, agreed that the labeling isn't perfect. Will workshop this in the next iteration, as this button will be serving dual purpose as a way to search in textual selections within a cell, as well as searching in multi-cell selections as the feature is currently. Thanks for the feedback!
Notebooks: ! Editor: ! Version: 1.90.0-insider Commit: Date: 2024-05-28T05:48:32.492Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Darwin arm64 23.4.0
Type: <bBug</bThe default width feels small, especially that we have 4 icons in the notebook find widget. It can only render 6 characters and then truncate. ! VS Code version: Code - Insiders 1.88.0-insider (, 2024-03-28T22:10:25.599Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (27)</summaryExtensionVersion ------ esbuild-problem-matchers0.0.3 vscode-eslint2.4.4 vscode-deno3.36.0 gitlens2024.3.2805 EditorConfig0.16.4 prettier-vscode10.4.0 copilot1.176.0 copilot-chat0.14. vscode-pull-request-github0.85. vscode-mocha-test-adapter2.14.1 vscode-test-explorer2.21.1 vscode-dotnet-runtime2.0.3 black-formatter2024.1. debugpy2024.2.0 isort2023.10.1 python2024.3. vscode-pylance2024.3.102 datawrangler0.29.6 jupyter2024.3. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.353.0 extension-test-runner0.0.6 test-adapter-converter0.1.9 vscode-github-issue-notebooks0.0.130 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
<!-- Please search existing issues to avoid creating duplicates. --- VS Code version: 1.59.1 Extension version (available under the Extensions sidebar): v2021.8. OS and version: Linux x64 5.13.11-1-MANJARO Python version (& distribution if applicable, e.g. Anaconda): 3.9 Type of virtual environment used (N/A ...): virtualenvwrapper Relevant/affected Python-related VS Code extensions and their versions: pylance v2021.8.3, jupyter v2021.8., Visual Studio IntelliCode v1.2.14 Value of the setting: Pylance from the VS Code marketplace to see if that fixes your issue] Extension loads successfuly Extension does not load, console reports "Unexpected token ' in JSON at position " [NOTE: Self-contained, minimal reproducing code samples are extremely helpful and will expedite addressing your issue] the extension by clicking a .py file <!-- Note: If you think a GIF of what is happening would be helpful, consider tools like , or . --<details<summaryOutput for <codePython</codein the <codeOutput</codepanel (<codeView</code→<codeOutput</code, change the drop-down the upper-right of the <codeOutput</codepanel to <codePython</code) </summary<p</p</details
Looks like you might have a bad update. Do the following to remove stale versions of the extension: Python extension (if you have pylance uninstall it first). all instances of VS Code. to, (on windows) or on Linux/Mac. any folder with the name starting with VS Code, and install Python extension (also pylance if you uninstalled it in step 1).
I followed all steps, but nothing changed. should I try to install older version of python ext?
Hi Can you try installing an older version of the Python extension, and if it doesn't work can you try a different version of VS Code (either an old one or the Insiders build)?
I've installed python extension , jupyter and no pylance. here's the log: As you said I'm going to install older version of vscode
Hi Did you try installing an older version of VS Code?
FYI - This looks like some JSON stored via the became corrupt.
The JSON is written a few lines lower, so it is unexpected that the value is corrupted. This might indicate some kind of bug in the storage layer. I don't remember writing that code, did you perhaps write that? Do you think it is so important such to fail extension activation when the JSON is corrupt, or should we catch that exception and return ?
I would suggest to be more resilient in extension activation as you suggest and fallback to an empty object here if any error rises from but log it as error: This is the first time I hear about a problem with persisting data into SQLite. However, seeing makes me think that this is not an officially supported Linux distribution.
curious if you could share the following 2 files with me (via e-mail is fine: find it on ). Steps: open the VSCode window where this issue happens View Command Palette =Log Storage Database Contents Help Toggle Dev Tools Find the 2 paths for the DBs send both files to me
I can still see the original issue in vscode-insiders v1.61.0-insider
whats the exact version you are on? And is it the issue that the extension fails to activate?
Version: 1.61.0-insider (user setup) Commit: Date: 2021-09-16T08:31:28.161Z Electron: 13.4.0 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: WindowsNT x64 10.0. python extension: v2021.9. Error 2021-09-16 17:51:12: Error discovering pytest tests: [SyntaxError: Unexpected token S in JSON at position at (<anonymous) at a.runTestDiscovery (PATH.vscode-insidersextensionsms-outclient) at runMicrotasks (<anonymous) at processTicksAndRejections () at async (index 0) at async _.refreshTestData (PATH.vscode-insidersextensionsms-outclient) at async v.refreshTestDataInternal (PATH.vscode-insidersextensionsms-outclient)] { stdout: '[{"rootid": ".", "root": "...
I fixed the issue as reported in that extensions fail to activate when the contents in storage fail to get parsed.
We support for auto-populating selected text to quick search (), but setting overrides this. This is because takes precedence over any default string (even if is defined). (from )
To me, this feels backwards... I'd want whatever was passed in to take precedence... and only if the default is set to the default value (aka the prefix) should the LAST be restored. was there a reason for this behavior that maybe I don't know about?
I do not remember. I assume you already bisected this to the origins?
the origin of this change came from: I now understand why this code behaves like it does. It's because it's provider (& prefix) agnostic. This code actually knows nothing about the prefix and nothing about the provider except the last accepted value per-provider. So basically, it's up to the caller of to say no don't .
I've sent a PR that makes the search one work as we expect.
verif steps: command, then search for some text and select one of the results. step 2, but make sure that the input that previously had is retained once you run the command. something in the pick to close it, then highlight some text in the editor. again. You should see your highlighted text in the input box.
<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --Steps to Reproduce: rename on a top level file element in explorer view in single folder workspace in developer tools that the div for that file row contains multiple invisible children elements which are input element containers !
I can not reproduce this issue on my machine. How do you end the rename, with Esc, Enter or some other way? Are you doing anything else that is special?
I just press continuously. I can reproduce this easily on linux(ubuntu) and windows. The setup it's just a folder with a single file and I drag and drop the folder on vscode.
Yes I can reproduce now.
This might happen again on tomorrow's vscode insiders. Thus unlocking converstaion so we can open this issue if needed.
You are right I can repro this again.
Issue Type: <bFeature Request</b The Test Explorer filter should be preserved if a window reload occurs, rather than resetting to default. This behavior could be gated by a setting. ! VS Code version: Code - Insiders 1.65.0-insider (, 2022-02-16T05:16:18.653Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (32)</summaryExtensionVersion ------ vscode-color0.4.5 vscode-opennewinstance0.0.12 gitlens11.7.0 filter-lines1.0.0 EditorConfig0.16.4 prettier-vscode9.2.0 copilot-nightly1.7.5030 remotehub0.24.0 gc-excelviewer4.0.50 todo-tree0.0.215 vscode-drawio1.6.4 change-case1.0.2 vscode-peacock4.0.0 git-graph1.30.0 vscode-azurefunctions1.6.0 vscode-azureresourcegroups0.4.0 vscode-docker1.19.0 remote-containers0.222.0 azure-account0.10.0 powershell-preview2022.2.1 indent-rainbow8.2.2 docthis0.8.2 pester-test2021.10.2 vscode-commons0.0.6 vscode-yaml1.4.0 vscode-inline-values-powershell0.0.5 errorlens3.4.1 vscode-icons11.10.0 codetour0.0.58 gistfs0.3.0 gitmoji-vscode1.0.9 better-align1.1.6 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
That makes sense.
I'm still able to reproduce this with the latest mainline build. May I pick this up since it's still open?
Sure!
When a quickpick has more items than can fit into the initial list, it's not obvious there are hidden items that need to be scrolled into view. The current visual treatment is a very subtle scrollbar flash when the quickpick is first opened, but thereafter there is no visual indication that there are more items. The current behavior presents issues for the remote indicator menu, which displays actions from all installed remote extensions (connect to host, create new codespace) etc. The remote indicator menu is meant to improve discoverability and ease of access to remote actions, and the current truncation inhibits discoverability of those remote actions. Proposals: a arrow button at the bottom of the quickpick when there are items offscreen which will scroll down to the next 'page' of items when clicked render the scrollbar
Looking at prior art here: Slack ! Spotlight ! GitHub ! Teams ! Alfred ! Docker ! One thing I'm noticing is that some render the height as the middle of an item... which is an indication that there is scroll. Not sure if that is intentional or not, but it would be something that we have control of. While the is a neat idea, I fear that it will be in the way while reading the item it is on top of... My preference is either render the scroll bar... or maybe do nothing since the "command palette" experience can be seen across many products and most if not all allow scrolling.
Oh, I wanted to point out that the scroll bar does flash today: ! and if your mouse is hovering over the list, the scrollbar sticks around. This feels like enough of an indication that there's scroll.
Instead of rendering it atop an item, what if we rendered it below all the items in the quickpick?
Do you not think the flashing scroll bar is enough? The Explorer does this too.
I don't think it's enough, particularly for the remote indicator scenario where you're triggering it by clicking the status bar--there will be a brief flash when it's first opened, and if you then use up/down arrows to navigate through the list, you don't see the scrollbar.
Is this a hunch or based on user feedback? I talked to a bit about how the fading went when we rolled it out everywhere and there were some issues opened: not scoped to quickpick but rather holistically.
We have settings to control the behavior but only in the editor I guess: ! in terms of proposal 1 for scrollbar visibility, I feel like the issues I linked are a better holistic way forward. As for the ... I'm not sold. Either it makes the quick pick taller (just for a little arrow) or it covers up content.... plus I couldn't find a single quick pick example in the wild that takes this approach.
I think it's fair to consider a global treatment for scrollable content as you say, the linked proposals look promising.
Proposed solution: increase the by a little bit so it renders like: !
steps to verify: open the command palette it should render in the middle of the item (like my last screenshot) to indicate that it does scroll
<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: master Ran into this issue while preparing Monaco release in vscode repo open monaco-editor test page switch monaco-editor-core source to not found error in Dev Console is registered through which is only read by workbench We can add the singleton services to standalone but a simple standalone service can also fix the problem <img width="576" alt="image" src="https://user-" let me know if you have time for a quick fix, if not I can push my change to branch first to unblock publishing.
FYI is also made to ensure work at this moment. Unluckily our intermediate typescript files for tree shaking don't apply to yet. The commit will be cherry-picked to master later.
There is no need for , the default implementation is good enough and just needs to be brought into the editor land.
please review
can you clarify the steps for this? I'm not sure where the monaco-editor test page is
I can take this one
<!-- 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.76.0 OS Version: macOS 11.6.2 Version: 1.76.0 Commit: Date: 2023-03-01T10:23:45.993Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Darwin x64 20.6.0 Sandboxed: No Summary When creating a profile with a name such as "Typescript / Javascript", the following happens: When exporting as a Gist, no result dialog shows ("there was trouble" / "created profile successfully") and a validation error is outputted in the logs When exporting to a local file, the text after the last forward slash is set as the filename. With the above example, it'd be " " To reproduce: a profile: Settings cog -"Profile ([...])" the profile: Select "Export Profile..." -"Export" the "name the profile" step, enter a name with a forward slash in like so: "Typescript / Javascript" either method for exporting: gist or local Expected results: If you select local: a system save prompt with the name you entered pre-set in the filename field If you select gist: A success dialog with a link to the website prefilled with your config Actual results: If you select local: only the text after the last forward slash is in the filename field If you select gist: No dialog shows.
The following error is in the "output" window, under "Window": I can only test this on a macOS device, I haven't tried this on a Windows or other Linux device and I feel like (with the area in mind - filesystems etc) these issues could manifest differently or not even be an issue there. I'm assuming validation on the inputbox for the name will be required because filesystems (and Gist? not sure) don't typically support forward slashes in file names. Thanks and if you're reading this, have a great weekend :)
Gists do no accept in the name. Replaced with .
Currently the hover disappear as soon as the mouse leaves the content hover. Sometimes the user leaves briefly the content hover. The ask is to wait until some times (ex. 500 ms) has passed before measuring whether the mouse is within the hover or not, then make the hover disappear or not.
This would be quite helpful in resizing the hover (because it's easy to go out of the hover when aiming for the angle to hover with a mouse). But I would think 500 ms is too much for that use case
Testing When find box is not visible and I just type but there are multiple results, then maybe allow me via keybindings (F3?) to go to next/prev result?
You mean using the type navigation feature? I think this would be too implicit. I don't know of any other native widget doing something like this.
I think the editor has a way to navigate in find results even without showing find. i think in that mode it only puts the search toggles up in a little overlay.
The editor opens up the widget once again, when pressing <kbdF3</kbd. Yeah we can do that.
I think the tree does the same, I had tried and it showed the input box, but it was empty though.
Yeah. Renamed this to remember the input across usages, which is what the editor does.
<img width="285" alt="image" src="https://user-"
strange as 1000 is a number <img width="1060" alt="Screenshot 2023-01-20 at 3 28 32 PM" src="https://user-"
value is here, not sure why <img width="1246" alt="Screenshot 2023-01-20 at 3 34 09 PM" src="https://user-"
Oh, changed the default value to 10 and it worked. I think 1000 is viewed as too high somewhere so it gets set to '' <img width="1052" alt="Screenshot 2023-01-20 at 3 39 55 PM" src="https://user-"
also tried because some other settings w high default values use that and it still didn't work
I some logging and it's because converts it to , and then the inputbox doesn't know how to handle the comma
When using the new diff editor with enabled, I very rarely get to the right editor position whenever I click the top action, above the editor.
You mean go to reference is broken?
diff editors have an action to open the original file (I think contributed from SCM?). When clicking that, expectation is that the current view state of the diff editors right hand side applies to the opening editor so that you stay in exactly the same view state (for example: the selection and viewport). <img width="140" alt="image" src=""
I really like the collapsed diff editor but this is a very frustrating regression from it which makes me want to shut it off. The issue is 100% reproducible in my usual workflow and I encounter this issue many times per hour.
I can reproduce. The "Open File" command is a mystery to me. Debugging shows me that is called twice, but both times with unhelpful stack traces: ! ! The second invocation sets . However, there is no reveal mechanism.
Further investigation showed that the "Open File" action is actually implemented in the git extension (even when comparing two files on disk) :/ Which I think is very questionable design, as it should be a core diff editor feature.