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.


What you report here seems different to me. Looks like the python extension is calling on something that is not valid JSON? Have you asked the Python extension what this could be?
I see, I'll create a new issue. thanks


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!


re see
same for
Same is true for Wanted to reuse the issue but didn't read all comments. Ignore mine. already mentioned it.
I'll change them to ,


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


<img width="642" alt="image" src=""
How do you repro this? We don't show the hint for readonly editors:
an file 1 -My guess is we don't re-evaluate the change


Users that don't want automatic updates should still be given the opportunity to stay in the same version. ping


<!-- 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


! should align more with <img width="672" alt="image" src="https://user-"


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.


Today when running out of sources and/or building, we get some components from online resources such as GitHub or our Marketplace. We should add SHA256 checksum verification to these: [x] [x] built-in extensions [x] electron
Adding the foundation for this for and extensions in


Type: <bBug</bExpected: ! Actual: ! Steps to Reproduce: a file. one configuration for any language. in ${} block and intellisense doesn't provide proper hints. More Info: bug is likely related to and . bug can be reproduced in 1.79.0-insider. VS Code version: Code 1.78.2 (, 2023-05-10T14:39:26.248Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No <!-- generated by issue reporter --
Going way back to , this change seems right since the configuration-editing extension has contributions for these languages but the extension doesn't actually activate unless I add explicit activation events. I can't figure out why the auto activation event isn't kicking in?
Oh, sorry--we revised the event to only do auto activation if the extension also contributed a language definition for that language, since otherwise this led to extensions like Python being activated too eagerly. For debug we should restore the explicit activation events too.
I see, thanks


I notice that when I edit our 1.9 release notes, the markdown preview seems to jump up and down all the time there is a change. Compared to 1.8 stable, this seemed to not happen.
Better, I still see flickering that it jumps up and down a little bit and the decoration to the left to show me the current edited location is also flickering. let me know if I should open a separate issue on that or if you think that is fixable.
The flicker should now be better than VSCode 1.8, but we can still do better. I've noticed the same sort of slight flicker on images in particular and on the current paragraph indicator as you noted. Please open another, lower priority issue so that we can track further improvements Thanks


Build:
Hit this again with
Again:
is trying to get more details when this happens:
Also saw this
This is because of atomic writing and in windows renaming is failing sometimes and I think this is because some other processes (defender ) might be holding the file that has to be renamed. I have seen similar issues in extensions when I implemented atomic installation of extensions long time back, ie. extracting the zip to a temp file in the same folder and renaming it. I have to retry renaming multiple times to avoid this. I am not sure if this is the right solution for FS atomic write. So, I would wait for until then I will revert my atomic write changes.
Check this issue - This is common in windows and it seems the workaround is to retry.
should the skipped tests be restored, I think they are still skipped
Seems like they can probably be restored.


Type: <bBug</bcc: Since Friday the 3rd, I have not been able to access the terminal accessibility buffer in my linux environment. I activate a terminal and am informed by orca about accessibility in the terminal. But pressing shift+tab does not move the focus to the accessibility buffer. Am I doing something wrong or has something changed from day 3? VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-06T05:21:55.128Z) OS version: Linux x64 6.1.14-200.fc37.x8664 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (39)</summaryExtensionVersion ------ doxdocgen1.4.0 vscode-markdownlint0.49.0 vscode-chatgpt3.9.4 rest-client0.25.1 better-cpp-syntax1.17.2 azure-pipelines1.208.0 vscode-docker1.24.0 csharp1.25.4 vscode-dotnet-runtime1.6.0 vscode-kubernetes-tools1.3.11 remote-containers0.283.0 remote-ssh0.99. remote-ssh-edit0.84.0 azure-account0.11.3 cmake-tools1.13.45 cpptools1.14.4 cpptools-extension-pack1.3.0 makefile-tools0.6.0 powershell-preview2023.2.1 remote-explorer0.3. vsliveshare1.0.5832 oracledevtools21.5.0 fabric8-analytics0.3.6 java1.16. vscode-xml0.25. vscode-yaml1.11.0 sonarlint-vscode3.15.1 cmake0.0.17 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-boot-dev-pack0.2.1 vscode-spring-boot1.44.0 vscode-java-debug0.49. vscode-java-dependency0.21. vscode-java-pack0.25. vscode-java-test0.38. vscode-maven0.40.


vscode-spring-boot-dashboard0.11.1 vscode-spring-initializr0.11.2 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
You can use this command for now, but I can repro the issue
The other change that has been made here is tab moves focus mode has to be on for that keybinding to work. This prevents issues where the terminal should be handling shift + tab such as for or autocomplete. The clause for this command can be configured in the keybindings editor though if you do not like this behavior.
After using the command Terminal: Focus Accessible Buffer, the behavior was a little strange. focus is on the accessible buffer, the tab key does not move focus to the terminal, but to the status bar. When I'm in the accessible buffer I need to press tab and then shift+tab to access the terminal. seems that the accessible buffer is not always updated when I execute a command in the terminal.
Yes thanks, covered in these issues:


there's an issue now because tabbing goes to the status bar instead of the terminal. I see that isn't set on the element. even when I set that explicitly, it seems like it's removed Originally posted by in


Testing Works on macOS but not on Windows 11 !
Works for me on Windows 11. at the lack of command start decoration on the following line in the screenshot where this doesn't work. !
Logs from
is happening after the next in the above, which is pretty weird. We try to detect quick fixes , so it's not surprising this is failing. any thoughts?
I likely caused this when making command markers more reliable on Windows
Seems this is broken for the non-polling case, which is why I am not seeing it (with starship).


From Language specific settings are behind proposed API flag
English
— when a fixed stable build can be expected?
Planning to release today.


Testing ! !
This is because of the same problem that caused
appears to be closed now, does that mean this has been fixed?
No, this issue is about fish acting atypical in that it applies the environment before is applied. This is because of how the automatic injection works in fish via an environment variable. Still not sure how we can handle this.
Discussed offline, maybe we could use the first pre exec hook in fish to run shell integration, instead of .
Nice !


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --For Anonymous functions code lens is displayed although it has only one reference. This is a lot of noise for nothing. In my opinion these lenses can be removed completely.
This issue lacks name of the language/extensions that you are using/showing
You are right. My bad. I fixed it. Sorry.
Requires: -
I in those required settings and am seeing the screenshot below. Seems to now only say 0 references instead of one but the code lens still exists !
I think the screenshot shows the expected (fixed) behavior. Previously the references codelens was on the line with . There are zero references because there are no uses of that class or method
yep - this is exactly what I wanted.


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Hello! Could you please allow for the output.ReverseAttributes to be defined as a user preference setting? This was implemented to and was implemented in the current emmet repo Why is this important? With Bootstrap, all of the generated code samples implement class attributes at the beginning of a tag. For example, a generated (As a note, this is how I've generally seen and used bootstrap classes implemented inside a tag), might have a section that looks like this: to add a new anchor with the same syntax, I would want to use the follow emmet syntax: However, the preview generated, and the implementation do not give me the style that I prefer: ! Now, I could implement a snippet for this specific anchor override, but now if I want to use this style across the codebase with all of my tags that utilize bootstrap, I now have to create a file that grows exponentially to cover every use-case. Since solves this behavior, I figured I could do add this override in my code workspace settings, such as But this did not work. also does not have a supported object for preferences based on . I think this might also open a bigger question of "How can VSCode support any arbitrary snippet preference? (There are many from where this specific attribute was implemented) There doesn't seem to be a method to implement this behavior via the regular so if I want this behavior today, it seems I would need to fork emmet and vscode, and implement my own custom implementation to enable this feature toggle.
thanks for the write-up. I wasn't aware of when output.reverseAttributes would come in handy. What I do know though, is that VS Code is currently using an older version of Emmet. Once it moves on to the newer version (the one you see at emmetio/emmet), it should be much simpler to get that preference implemented. I'll keep this issue open in the meantime.
Sounds great! Thanks for the quick response, looking forward to the newer version of Emmet being implemented!
Created a PR fixing this


Today which have which triggers quick pick to select a file. This issue is about also allowing to type a file name and have dynamic suggestions, like inserts


<!-- 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.63.2 .Steps to Reproduce: an error while coding, and open the "View Problem" box. that the up-arrow has the label "Goto next problem". Ideally it should be "Goto previous problem". !
You accidentally closed this let's reopen and assign to me. fyi


LSP now support pull diagnostics. Adopt for [x] CSS [x] JSON [x] HTML


<!-- 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.84.2 OS Version: win10 Steps to Reproduce: Theme: Dark Modern two cpp files in the workspace, move the tabs upwards and downwards respectively. +N, Open a new Tab, and copy some content into it. Move the tabs upwards and downwards respectively. When I move tabs downwards, the edge color disappears. Another sample This issue can be reproduced in vscode-insider
I'm not able to reproduce this. Can you check if you see an error in the dev console? Run the command and check the console for errors.
You can try with a larger cpp file, simply copy code to many lines. Drag the tab down to change the tab's position
It seems the tab scrolls down, so the color bar is blocked
I was able to reproduce it now. The reason I was not seeing it was because it only appears at specific zoom levels. Looking into it...
Thanks for the help we were able to fix it
This problem seems to still exist in the latest vscode-insider. ("window.zoomLevel" : 0 ) 86.0-insider x64 With untitled tabs, the tab can be scrolled down and up, Besides, It seems that the .json file is an exception


Depending oh how many editors windows are open and the size of them, sometimes the standalone color picker is partially hidden behind other editor panel. vscode version:1.81.0 x64 !


There is a z-index error: <img width="572" alt="Screenshot 2023-07-25 at 13 56 59" src=""


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.


Microsoft/vscode Repro: PR ext description page something, shift+tab until you hit the start of the screen There are 4 focusable items, close, next match, previous match and the find input.
Would you like me to start on this?
Yes please. It is too late to get a fix in for the January VS Code release but you can submit a PR any time and we'll try to get this fixed for February
LOL ... my Dragon dictation did the equivalent of a butt dial , deleted assignments and pasted an eMoji sorry about that :-P
FYI: started on this and I can reproduce and see it. simpleFind transitions in and out with animation, hidden only because of z-index and/or overflow. The widget always has display type:flex , therefore the four tabs stops for the buttons and input are always in the tabIndex order fix should be simple, however, there is an interaction between the animation and the display mode such that simultaneously going from display:none =flex messes up the animation. I'm working on separating the display mode from the transition to see if that will work. I have to do more experiments , May have a question or two later...
See PR: Verification: Use a screen reader with screen output on so you can see and track each tab stop Open the new pull request extension page Click on the upper pane to begin focus there Tab through the various toolbar buttons , after dependencies the next tab SHOULD land on With the webview not the simpleFind widget. Verify showing and hiding simpleFind has smooth animation as before Note: When focuses on bottom for web view pane , screen readers output a bunch of base64 encoded text (see truncated output lines below). But I think this is an accessibility bug, if you guys agree I'll post an issue. NVDA Output: with visibility fix (correct output, no tab stops within the hidden simpleFind) NVDA Output: original scenario without fix (can see tabs stops in widget)


Issue Type: <bBug</bI have been using for a long time. Currently I end up with a LOT of inadvertant selections when working in two side-by-side editor groups and switching back and forth between them using the mouse. The reason is that the editor scrolls 5 lines every time I click into it. VS Code version: Code - Insiders 1.58.0-insider (, 2021-06-11T05:22:19.992Z) OS version: Darwin arm64 20.5.0 Restricted Mode: No Remote OS version: Linux x64 5.4.0-1046-azure <!-- generated by issue reporter --
I cannot reproduce. Does this reproduce for you when disabling all extensions? (The editor exposes a API to extensions). I have recently also got which seems incredibly similar, but I am having a hard time reproducing any of the jumping that is described. Here I am trying two side-by-side editor groups: https://user-
This reproduces only when the language mode of the files are set to markdown. I think this has to do with how the markdown extension is using the vscode API. But I think it should not use that API at all if no markdown preview is rendered. But it would also be interesting to test what the experience is when the preview is rendered. Given this doesn't reproduce with txt files, I'm optimistically giving this to you. Steps to reproduce: define open two md files side-by-side (preferably without word wrapping to see the top line number change) click on the editor tab of each one on every click, the editor scrolls up by 5 lines https://user-
Could you please take a look at this since you were looking into markdown syncing last iteration?
It seems like it's a bug coming from the scroll syncing between the static and text editor changes that I made a while ago. I'll try to make a PR to fix this soon.


<!-- 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.88.1 (Latest) + GitHub Codespaces OS Version: All? (Tested on Linux + MacOS) Steps to Reproduce: a folder or workspace (create if necessary): all the content from the above file and save it the command palette 'Tasks: Run Task' '+ Configure a Task' 'Open file' any provided task template notification error: "Unable to write to Folder Settings because no resource is provided." Expected behaviour: Empty is populated with the contents of the selected task template <img width="898" alt="Screenshot 2024-04-18 at 16 50 01" src=""


! should be highlighted: ! Version: 1.77.0-insider (user setup) Commit: Date: 2023-03-21T05:22:13.879Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
cc for TS
I cannot reproduce, semantic occurrences seem to work fine for me. can you reproduce running from source? !
I can repro out of sources as well
Looks like a windows specific issue (slash vs backslash): ! ! (in TypeScriptDocumentHighlightProvider.provideDocumentHighlights)
Reverting fixes it.
Hm I don't think this was caused by . Instead I suspect the root cause was


This seems really aggressive and probably not intentional <img width="406" alt="image" src="https://user-"
I think this rule references a css variable that isn't defined <img width="501" alt="image" src="https://user-" it looks like you were in this area recently, it looks like there is a default that we don't fall back to, do you know what's going on?


<!-- 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.71.0 () OS Version: macOS 12.5.1 (21G83) Steps to Reproduce: any file on . the filename tab on the "Editor", hold + Click on it (the same as a right-click or two-finger click on macOS). See the image below ! Expected: it opens the context menu with options about the file. Actual: it blinks the context menu for a fraction of a second. A screencast of the problem: ! The problem doesn't happen on VS Code desktop.
I can reproduce, and maybe is an issue that would reproduce on desktop too but we use native menus there and not custom menus.
is this ctrl+click behavior mac specific?
I am not entirely sure, but so far, we have only seen reports about this issue on macOS.
Yes, Macs by default consider CTRL+Click a right click. This works across the entire OS.
This is great, thanks for the fix!


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --This proposal affects Settings editor (Settings UI) users and extension authors. The search in the Settings editor currently shows results sorted by the table of contents so that commonly used settings can show up at the top, and so search results can be grouped by the entries in the table of contents. The change to sort the settings by table of contents was made as part of and However, the Settings editor performs two searches per query: the first search finds settings based on keyword matching, and the second search attempts to find relevant settings using similarity search algorithms. As a result, the second search is prone to finding less relevant settings, especially when the user had a specific keyword in mind. Because the Settings editor currently orders settings by the table of contents, the less relevant results from the second search sometimes end up showing above the keyword match results because they appear first in the table of contents. As an example, if I search "title bar style" in the Settings editor, actually shows up fifth due to table of contents sorting: ! This issue proposes reverting the settings search so that the keyword matches always appear at the top of the search results again. As part of this proposal, and would regress and become out of scope. In other words, ordering the search results so that keyword matches always appear first would break grouping the search results by the table of contents entries, but would make it so that users hopefully don't have to scroll down as much to find what they were looking for. Implementing this proposal would also break sorting extension search results by the settings order numbers given by the extension author in their extension's file. I noticed that the issue of having to scroll down to find a keyword match is made worse when the Settings editor is "small", such as when I restore/shrink the VS Code window. Screenreader users might also have to tab down more search results to get to the one they want. Feel free to upvote the proposal if you'd like to see it implemented, or downvote it if you'd like the settings search results ordering to remain the way it currently is. You're also welcome to comment on this issue with alternative suggestions for how the search results should be shown within the Settings editor.


Pinging authors of the issues above along with those who I have seen express interest in reverting the behaviour:
Another idea I have rather than doing a full revert is to use table of contents order as a last resort sorting key for the keyword matches. Therefore, keyword matches in the title could come before keyword matches in the description, and the settings that all have a description-only keyword match could be sorted amongst themselves by table of contents order. With this concept, some extension settings could preserve their order, but an extension setting found by keyword matching would still always come before an extension setting found by a similarity algorithm.
To revert the search results in the Settings editor to order by keyword matches first in the Visual Studio Code extension, you can follow these steps Open the Settings editor: You can do this by pressing the Ctrl+, (Windows, Linux) or Cmd+, (macOS) keyboard shortcut, or by clicking on the gear icon in the Activity Bar and selecting "Settings" from the dropdown menu. Search for the "workbench.settings.settingsSearchTocBehavior" setting: In the search bar at the top of the Settings editor, type "workbench.settings.settingsSearchTocBehavior". Change the value of the setting to "hide": Click on the dropdown menu next to the setting and select "hide". This will disable the table of contents ordering and prioritize keyword matches. Restart Visual Studio Code: To apply the changes, you need to restart Visual Studio Code. Once you restart, the search results in the Settings editor will be ordered by keyword matches first.
that behaviour was implemented as part of , and yes, it is a workaround in a sense. This proposal is on ordering results by keyword matches first even when the table of contents is shown.
Try doing this way In the file, add the following property to the contributes section: { "name": "revert-settings-search-to-keyword-matches-first", "version": "1.0.0", "description": "Reverts settings search in the Settings editor to order results by keyword matches first.


", "publisher": "your-name", "categories": ["Settings"], "activationEvents": ["onStartup"], "contributes": { "configuration": { "properties": { "search.settings.sortByKeywordMatchesFirst": { "type": "boolean", "default": true } } } }, "main": "" } the extension's main script file, add the following code: const vscode = require('vscode'); vscode.extensions.onDidChangeConfiguration(() ={ const sortByKeywordMatchesFirst = vscode.workspace.getConfiguration('search').get('settings.sortByKeywordMatchesFirst'); // Update the Settings editor's search sorting algorithm here. });
Since I am coming from , it would be important to me that the order determined by the extension is retained when only " is called (as you also suggested in ). This then serves as a filter for the items in the base order. If you then place a keyword behind it, you can search "smartly" again.
Verification notes: for title bar style should show the setting first no matter what value is set to. for should show the CSS category first, followed by the LESS category, and lastly by the SCSS category.


Type: <bBug</bany open windows. to File Open Recent and click Clear Recently Opened. VS Code version: Code 1.83.1 (, 2023-10-10T23:46:55.789Z) OS version: Darwin x64 20.6.0
<!-- 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


VSCode Version: 1.36.0 OS Version: Windows 10 Repro steps: Live Share extension 1.0.488, start a collaboration session two comment threads on a single line. Comment on a line, 3 for example Comment on a second line, 4 for example Delete line 3 Now there are two comment threads on line 3 (the line that moved up from 4) /Collapse the comments with the marker Collapsing/opening such comments might need a rework. Currently I can collapse each individually, and if all are collapsed (or all open), the box on the gray line opens (or closes) all threads. However, if only some of the threads are collapsed, the gray box toggles between the set of open threads and the threads which were collapsed. It never collapses all threads to return to code, and requires each remaining thread to be collapsed individually. Originally reported in Live Share issue
As I was just about to file the same thing, here is the screencast I created for illustration: !
I agree the current behavior is a bit confusing. Clicking in the gutter is a common way to collapse open comments. However, the workflow fails when multiple comments are on the same line. This forces the user to think and use the alternative workflow (top-right icon). Suggested behavior: if at least one comment is expanded, collapse all comments on the line otherwise, expand all the comments The condition could also be reversed (expand if the line has both expanded and collapsed comments).
Since we just came across the relevant code again in another context: clicks on the gutter icon currently toggle the collapsible states for all threads on that line independently here: already exists as a private property, if there was a public getter for it, behavior like the one suggested by above could probably be implemented very locally in the location I linked to above. let us know if that sounds reasonable and we can make a PR.
yes, this sounds reasonable to me. l would accept a PR!
I opened .


Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.77.2 OS Version: Windows 10 It seems that when refreshing () the in a short period, the second refresh is not actually performed. I have provided an example repo and a video demonstrating the issue. Basically we have a that shadows the active editor so whenever a user changes the active editor we update the read only document. However, if the user changes the editors quickly enough then the second change is dropped... Steps to Reproduce: the extension the command "Open Read Only Document" tabs quickly and see how it falls behind even though the content is up to date https://user- The content is actually set but it seems the second is dropped. Because if you refresh the document manually it shows the correct content (see the video above). The issue seems to happen more frequently if the content of the file(s) is large.
I found out why it happens and attempted a fix (with explanation) in
Pinging so it does not get lost


Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-


Issue Type: <bBug</bclick folder some chars and drag to the left to release GIF ! VS Code version: Code 1.41.1 (, 2019-12-18T14:58:56.166Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (29)</summaryExtensionVersion ------ vscode-css-formatter1.0.1 markdown-preview-github-styles0.1.6 vscode-intelephense-client1.3.9 vscode-markdownlint0.34.0 vscode-html-css0.2.3 php-debug1.13.0 auto-js-vscodeext0.2.3 composer0.7.1 markdown-shortcuts0.12.0 hex-rgba-converter1.0.4 php-namespace-resolver1.1.8 code-beautifier2.3.3 vscode-language-pack-zh-hans1.41.2 remote-ssh0.48.0 remote-ssh-edit0.49.0 remote-ssh-explorer0.49.0 cpptools0.26.3 Go0.13.0 php-docblocker2.1.0 vetur0.23.0 vscode-php-getters-setters1.2.3 minapp-vscode2.2.2 java0.55.1 vscode-xml0.10.1 datetime1.0.5 code-settings-sync3.4.3 vscode-java-pack0.8.1 vscode-preview-server1.3.0 html-css-class-completion1.19.0 </details<!-- generated by issue reporter --
I can not reproduce this. Thanks for filling this issue. Can you reproduce using Visual Studio Code Insiders
reproduce too !
I can not reproduce this both on macOS and Windows and I am doing the same thing as you. Let's leave this open as see if more users hit this. If you are interested in providing a PR which fixes this, here's a code poitner
reproduced as well, make sure you release the drag on the arrow icon.
pushed a fix for this. Please try it out in VS Code insiders from Wednesday and let us know if you still see the issue. Thanks
Thanks, but have a new problem: Input is cleared !


Yeah I also saw that, it's caused because when "expanding" the row element the tree refreshes and the previous value in the input is lost. But I think that doesn't look as bad as the previous behavior where the children got duplicated


Build: Changes:
does the error ring a bell? Should we be running with ? Besides, many crash dumps again, such as:
Crashes are tracked in As for GPU initialization failure, it could be due to various reasons depending on the hardware. Need additional logging to identify the cause . I would suggest to disable gpu, since it is not worth addressing them for CI.


VSCode Version: code-insiders-1.8.0-.el7.x86_64 OS Version: CentOS Linux release 7.2.1511 (Core) Steps to Reproduce: code rpm from insiders build on CentOS minimal to launch it from cli Installing GConf2 fixes it ( yum install GConf2 ). maybe should be a dep in the rpm spec file.
hello would love more information on the minimal install aspect for your use case. To clarify, are you starting with a "minimal installation" and then installing x11 after the fact ? !
Yes, and after that I just install the basic fonts and xorg xauth because I ssh into the devel box and use the editor via X11 forwarding. I've done this with other editors and is pretty handy, so I can avoid copying/checking out code from the workstation to the devel box (I write stuff meant to run over CentOS 7)
The exact same problem occurs on Elementary OS (based on Ubuntu). Running fixes the issue. It's most likely the same missing dependency problem in the .Deb file.
this should be fixed in 1.9
Hello, I had the same problem on openSUSE 42.1, when I ran the problem was solved. Btw I downloaded the .rpm file.
On ArchLinux pacman -S gconf


Issue Type: <bBug</bOpen a Webview (for example: Help -Release Note) and start the search (Ctrl+F) and write the search term (for example: "Update") Only "u" (first letter) is selected on the view and not the current tipped search term. ! Notice: If i pressed "enter" then the full term is selected on the view. This behavier was other in the previous version (1.52.1) VS Code version: Code 1.54.3 (, 2021-03-15T10:55:45.459Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (31)</summaryExtensionVersion ------ mock-debug0.45.4 cortex-vsc2.1.0 npm-intellisense1.3.1 vscode-markdownlint0.40.1 jshint0.11.0 vscode-eslint2.1.19 vscode-npm-script0.3.18 vscode-firefox-debug2.9.2 auto-close-tag0.5.10 code-runner0.11.3 vscode-test-explorer2.19.6 code-coverage1.2.3 vscode-docker1.11.0 csharp1.23.9 python2021.3. vscode-pylance2021.3.3 jupyter2021.3. cpptools1.2.2 powershell2021.2.2 debugger-for-chrome4.12.12 vetur0.33.1 java0.76.0 vscode-xml0.15.0 vscode-yaml0.17.0 markdown-preview-enhanced0.5.17 vscodeintellicode1.2.12 vscode-java-debug0.32.1 vscode-java-dependency0.18.2 vscode-java-pack0.13.0 vscode-java-test0.28.1 vscode-maven0.28.0 </details<!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.526 --<!-- potentialduplicatescomment --
The search behaviour changed between Electron 9.3.5 and Electron 11.4.1. The parameter should now be whenever we're doing a search for the first time.


[X] Notebooks (.ipynb files) [ ] Interactive Window and/or Cell Scripts (.py files with #%% markers) Hello. As the title says, I can't make a internal link in a jupyter notebook in vscode if the cell's title starts with a capital letter, contains an underscore or contains a space, as you can see on the images. Also, on the sole option that it works, non-capital letter header, when clicked it brings me to the bottom of the notebook, and the focus is not brought on the right header itself. Initial tests: ! The test headers: ! 64.5 v2022.2. Python v3.8.5 Python Extension: v2022.2. No response Local
This is actually handled by VS code core (and not the extension). I've included a demo notebook that repros the problem .
In the demo notebook, the href jumps all work ! But none of the header jumps do unless you rewrite them to be only lowercase. All of the links work fine when running in 'jupyter'.
Vscode this notebook is still with all the bugs. Even on the links that work, they jump me to the very bottom of the notebook, not to cell 2, cell 3 or cell 4. Also Section jump and Section with space jump still doesn't work at all. I'm using portable Vscode btw, but I think this doesn't make any difference since when I was using the regular one this bug still existed. Even now, about 2 years later (that I recall) it still goes on on notebooks in Vscode. I can record a GIF if you need. I assure no weird magic was done on my vscode, just regular installation and all... and I can confirm that this issue still occurred years ago on my other PC too.
Does this reproduce in the ?
It did for me.
Will this issue be addressed on any new version of Vscode? I've headed to version 1.67 and to "April+2022+Recovery+2"+is%3Aclosed and found no mentions of this issue. Perhaps on the next, if it would be implemented/fixed at all? Thanks anyway! :)
This issue was fixed in 1.68 (the May 2022 milestone)
got a look at and pull request ( ) doesn't appear there.


Will it be ? Thanks :)
Did you test it?
Yes! everything was fixed. Capital letters, underscore and space headers now work like a charm. I was just asking if this specific commit ( ) will be listed on the update website. I don't know how it works, if minor fixes won't get listed or something like that. I just wanted to show to some friends that somehow I've contributed to Vscode with my bug report Anyway, everything buggy was fixed. This issue may be closed anytime.


Testing So I was testing the terminal sticky scroll and I noticed that the sticky code block disappears in an abrupt manner when the beginning (not the end) of the multiline terminal command, reaches the end of the scope. To give more context about what I mean, I the GIF below. I was sort of expecting the code block to start disappearing when the line reached the end of the output for that command. I noticed that the code block disappeared however when the line reached the end of the output for that run. I don't think this is a problem per say, it's a different manner of animating sticky scroll. I was just wondering if this is intended? I think the potential issue with this approach is that the sticky scroll block is hiding the next terminal command and its output while you are scrolling until it disappears. In the editor, sticky scroll starts disappearing progressively when the bottom of the last block/line touches the end of the scope. Perhaps we could explore something similar?
This is actually a bug, it's meant to scroll up as in the editor and was doing that at some point. Note that it's not as smooth as the editor since there's no "partial line scrolling" in the terminal
Repro that demonstrates more clearly what's happening: Run: Run: Run: when scrolling, sticky scroll from a command should never obscure the command below it like this: !
I see the prompt line sort of being obscured here


I try to add a keybinding with ${selectedText}. but it will resloved as a normal string. Steps to Reproduce: ! Version: 1.75.0 (user setup) Commit: OS: Windows_NT x64 10.0. Sandboxed: No
would you happen to know why the variable isn't resolving to a value here? Is there something that the command must contain to resolve variables?
The decision for whether variables should be resolved in a command needs to be made on a per command bases. If you want, you can run your commands arguments through the variable resolve when your command is called. For example, the terminal uses the variable resolver here:
From It would be great if more variable resolution was achieved in keybindings - I think it has been requested many times.
verif steps: a keybinding for : that the keybinding correctly sets to the current path.


When creating a breakpoint in an active debug session and this breakpoint cannot be verified, the resulting icon is almost invisible: ! The problem is that the icon's stroke is too thin. In previous versions the icon had a thicker stroke: ! I suggest that we restore the previous icon.
Agree that it is a bit too light. I do not just want to take the previous icon since the color and style are different. Thus it would be great if could tackle this Also fyi
Not quite as strong as in the 'before' above, but stronger. Marking verified. !


Type: <bFeature Request</bCC Just like other audio cues, please reduce aria alert when "" is used. VS Code version: Code - Insiders 1.84.0-insider (, 2023-10-17T05:34:42.128Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
also when is used
To verify, Enable Enable a screen reader Format a document Verify that the screen reader doesn't alert and you just hear the audio cue
Verified, but found this:


Originally reported by
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
would you mind verifying this one please?


Open Set some breakpoints They show in the wrong place and cover a character, but seemingly get fixed when setting a breakpoint on the next line !
It is non-deterministic: ! Maybe that depends on the timing of the debugger. If I add to this statement (effectively removing the condition), I cannot reproduce anymore: Unfortunately that might cause performance problems. I think this is because needs to be called when injected text is inserted before it.
I am currently still reproing it here: <img width="445" alt="image" src="https://user-" btw make sure you add labels and a milestone to issues for verification and tracking
Any chance this could be looked at soon? It comes up pretty often <img width="1018" alt="image" src="https://user-"
Thanks


Testing There are "" "notebook.outputLineHeight" "" "notebook.outputFontFamily" "notebook.outputFontSize" Ideally these would be all namespaced or prefixed .
This affects how they show up in the settings editor UI, btw: <img width="919" alt="image" src="https://user-"


Following on from comments at , it would be good to have basic Dart language configuration as a built-in extension in VS Code, allowing things like syntax highlighting to in the case where the Dart extension is not installed (for example a Live Share client that hasn't installed it) or is disabled (for example in an Untrusted workspace). From : There is a Dart Team-owned grammar here that can be used - it's the (except for a small bug fix that I'll file an upstream PR for shortly): Great! Though what's the advantage of depending on the built-in extension? I try to support a few-versions-old VS Code where possible (so wouldn't do that for a few versions) but also the extension is published to open- for use by other clients so the dependency may complicate things (if they don't have the same built-in). I'd probably do some investigation into this before removing anything from Dart-Code then (it sounds like there's no downside to having the grammar/config provided by both for a period anyway). (fyi
It also works without a dependency, but only because the extension is built-in. No problem if the Dart extension keeps the grammar and language configurations for a while until it is all settled. Do you want to look into a PR or should I?
If it's easier/quicker for you to do, feel free. Otherwise I'm happy to do it but may need some pointers for how built-in extensions are set up.
I pushed the PR We have a new built-in language :-)
Super, thanks! For future reference - for changes to the language config I can send a PR to , and for grammar changes I can run (after the changes are landed in the upstream dart-lang repo)?
I just noticed in the it has the path but this doesn't seem to match the location of the file ?
Good catch, thanks. Pushed the fix:
For grammar changes, I'll pull them in about once per month so you can just rely on that if you want. If there's a change that needs to be picked up sooner than that, then feel free to make an issue an @ mention me and I'll pull in the change earlier.
Perfect, thanks!
is this support in the Code May Update (1.57) that just went out?
Yes, in microsoft/vscode you can tell what release an issue is in by looking at the Milestone. !
Yep!


An easy way to test it's working is to disable the Dart/Flutter extensions (accept the prompt to reload), then open a Dart file. You'll now still get syntax highlighting (note: you won't get analysis or much other editor functionality, that requires the Dart extension). <img width="650" alt="Screenshot 2021-06-14 at 15 52 25" src="https://user-"
Yeah I just did, and it works great :-)


! Notice the red icon, I find that somewhat unexpected. //cc
I bisected this to gonna add you to assignees.
Thanks for tracking this down.


The change for went in without a UX discussion. IMHO we should reconsider adding these two actions to all editor context menus. IMHO we need to be more critical with adding things there and have good reasons to do so. <img width="284" alt="image" src="https://user-"
I figured it wasn't a major change since they are already in the context menu during a debug session. Would a Debug submenu help? Or how about only showing them if the user has previously debugged in this workspace?
I see how it might not feel like a major change, but IMHO we should approach this with a different mindset. We have many useful commands, and we can add many of them to the context menu, but just because we have the ability to add them is not IMHO a good enough reason. Adding something to the context menu has two disadvantages: it makes our editor feel bloated (think typical IDE of the early 00s) it detracts from the value of the existing items, since there are so many of them. I think we need to have a good reason to decide to always show something in the context menu, like a very important feature that we feel will differentiate VS Code from other editors, a reaction to a lot of user feedback, an action which would make the product incomplete if it would be missing, etc.
We discussed this in standup and I will likely just remove them when not in a debug session.
From and Keeping the changes so that they will work and appear in the command palette when not in a debug session, but only appear in the editor context menu while debugging


When the content hover contains a color picker and it is resized too small, the text and the color picker box overflow. Perhaps the text should disappear when there is not enough space for the text.
At least the text does not wrap to the next line anymore, but imho the text should remain visible for as long as possible and could possibly also have text-overflow: ellipses? <img width="153" alt="image" src=""
Hi thanks for your comment. The following PR which was merged yesterday should set a minimum width on the content hover when a color picker is embedded and resolve the issue. The fix should appear in today's insiders with commit number
Indeed, thanks!


Hovering inlay hints should show problems "underneath": !
Came here to report the same thing https://user-
This happens because inlay hint have their own hover which are anchored on a . The diagnostics hover explicitly checks for that and . Would be OK to pretend to be a "normal" range hover anchor so that I can get all the hovers together? Or should the diagnostics hover not check for the hover type?
The is used both by inlay hints (via ) and ghost text (directly instantiates it). I think in the case of inlay hints you would want that markers are rendered in the hover, but perhaps ghost text wouldn't want that they appear in the hover, it might want to show only these actions: <img width="598" alt="image" src="https://user-"My suggestion would be to add something to to be able to distinguish the two cases.
Can still repro this
Please update this issue with a real code snippet that allows to reproduce this, please update this issue with what you have tried. Thanks
I just found a reduce function in VS Code sources such as and replace the returned value with the void keyword such as
Something like this only gives a squiggle for the return value, not the arguments or anything with inline hints. To clarify, this will only work for squiggles that spawn across inline hints <img width="699" alt="Screenshot 2023-01-26 at 14 49 07" src="https://user-"
Hmm, maybe it's because it's in a function so the return value becomes incorrect? This in <img width="917" alt="image" src="https://user-"
Thanks for updating
Looks good to me. Version: 1.75.0-insider Commit: !


<!-- 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. --- Version: 1.75.0-insider (Universal) Commit: Date: 2023-01-10T05:21:34.436Z Electron: 19.1.9 Chromium: 102.0.5005.194 16.14.2 V8: 10.2.154.23-electron.0 OS: Darwin arm64 22.2.0 Sandboxed: Yes Steps to Reproduce: an existing workspace folder with git a few branches with commits to switch branches list of branches does not display the recent branches on top the same workspace folder in vscode stable and the order is as expected


I started seeing this error since yesterday, then remembered that I this setting trying to commit from scm view: ! saving the file which triggers : !


Issue Type: <bBug</bI remapped command to [Alt + V]. And such keybinding doesn't work. KeybindingService log is as follows. Keybinding seems to pass through vscode to terminal since when I run in terminal it registers keypresses. VS Code version: Code 1.67.2 (, 2022-05-17T18:23:40.286Z) OS version: Linux x64 5.15.41-1-MANJARO Restricted Mode: No Remote OS version: Linux x64 4.19.119-30.2 <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This is working fine for me, I do see the warning that I don't understand though. any insights into what could be happening here? Could the soft dispatch teh terminal does be causing problems with this ignore single modifier thing?
Yes, I think is not dispatched through the keybinding service in this case. Looking again at the OP log: And comparing it with the output I see when binding to : Notice how the OP's log does not contain the keydown event for (i.e. this line ), but there are logs about being dispatched. I think the logs about being dispatched relate to the call the terminal does, but it looks to me that the keybinding service doesn't really get to dispatch the keyboard event, so it doesn't execute the command. I see how is making the log confusing so I will push a change to improve logging to better distinguish between and the real dispatch.
do you have or set in your
Yes I have enabled, but I didn't override . As far as I understand is included in by default.
It is but when is set to true it overrides as a convenience setting for users who use a lot of shell-based keybindings. If you're getting into needing to customize , I'd recommend setting back to false and tweaking instead. I checked the docs and it looks like this is already explained so I don't think there's anything we need to do on our end: !
ok, thanks a lot for your help


<!-- 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. --Something has changed in the latest Insiders so our CI started to fail with errors (any branch but here is an ): Do you have any idea what might cause it so we can make changes on our side? Might it be something with your dependencies?
Runtime has no changes with insiders, this seems like a regression from the recent http proxy changes based on in upstream. Passing onto From a quick look the extension relies on package which makes network connection. it would be great if you can reduce the test case to a minimal extension sample for us to debug this issue further. Thanks!
Unfortunately, we haven't been able to isolate the issue for a minimal extension sample so far. To reproduce the problem, you can follow these steps: the and install the extension. the following commands in the terminal: When running all tests, you may observe multiple failures with the . However, when running the failed tests separately, they randomly may or may not fail again, which makes it hard to identify the cause of the issue. It is possible that your proxy patches might be the right place to look for further investigation.
Maybe a related discussion:
Found it. The place in our code that fails with the latest Insiders is . I created a so you can try it, but here is the code snippet for a quick look:
Thanks for putting together this test! My investigation so far: is called with resulting in the reported error when it calls here: The check at would prevent from being called when , but that is only with in 19.0.0.


Still need to check older versions to see if that check was backported and see if there is a way to test this assessment.
is available in 18.8.0 and 16.18.0, our exploration builds based on Node v18 has this change, you can use the builds from to verify the assessment.
The test does not reproduce the issue in the exploration build. Still trying to understand what is happening (please ignore the above code pointers) by looking at the code at the tag. I see the failing call to being triggered in : What I don't quite understand is that the callstack to with comes from : But at that line is supposed to call not as it appear in the callstack: Could you point me at the source that went into Electron? I believe that is not the exact same as that at
Electron pulls source from when building, what you are looking at is the correct one. I think the async stack is missing a trampoline calll, but you are seeing a write after shutdown stack same as
Thanks This looks like an upstream issue to me, should not be called when is already . I don't see the change in 18.15.0 (the version the exploration build is using) yet that might have fixed it.
We have reverted to the previous way of loading certificates as we are getting close to a release ().
We're seeing this again in our macos and Windows CI jobs for VSCode "Insiders" (not current VSCode stable version 1.82.2). Was node or electron updated in the last 2 days on VSCode Insiders?
There is fix in upstream for the above scenario, I will backport it to relevant release lines.
Could you confirm that todays Insiders build fixes the problem? Thanks!
Confirmed, thanks!


Testing Open keybindings editor and interactive window in two editor groups Check that input editor has shift + enter as keybinding to execute Change the keybinding to some other key Placeholder is not updated
This doesn't seem to work for me on Windows:
sorry that's the wrong command, the Jupyter extension contributes multiple Shift+Enter keybindings. Could you please try changing the extension's keybinding for ? E.g. !
Thanks!


I just now noticed how the progress bar was a the very end of the quick pick but not below input box, I think it should be below input box because the progress is for what I typed. Steps: have some history entries in Cmd+P picker be on a slow OS (Windows) start to type and notice progress bar is below the history entries //cc
Seems like this might have been a regression at some point. for relocating it back near the input.
I like where it is now. To me it says "the results are still populating".
The reason I do not like it: the progress bar is at a non-deterministic location depending on the number of items the progress bar indicator is away from the location that triggers it (the input box)


For
Verify: write an extension that exercises the following APIs by passing in a selection as option and verify the selection is revealed and showing up in the opened editor: command API Provide a property of type to get it. !


<!-- 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 VS Code Version: 1.61.0 (I've seen this before and see it on too) OS Version: MacOS 11.6 Steps to Reproduce: Have 2 editor groups in workspace. Open a search editor (Cmd+Shift+F [can't remember if that's a default or my custom keybinding]) it to the other editor group. something to search for. At this point, you have to scroll up to see the results.
I've been looking into this. Any ideas where to start? I see that the following code does get called, but doesn't seem to position it correctly. If I wrap in a for 500ms, it works, but that's not a good long term solution.


VSCode Version: Code - Insiders 1.5.0-insider (, 2016-08-09T16:02:06.523Z) OS Version: Darwin x64 14.5.0


Testing Unfiltered notebook noob feedback: ! I was expecting a tooltip to tell me what it meant.
Agreed that we should add tooltip for it.
how would you interpret it if there was a tooltip that said "Execution Order"?
when you run all cells it goes in that order? I was expecting that to be sequential from the top?
It's the order that it was executed it, not the order it will execute in. Hopefully a user would figure that out if they run the cell and see it change.
oh, more explicit would be better then imo I also question why this is useful but I'm guessing this is a common notebooks feature elsewhere?
Yeah it's what people expect from Jupyter and can help you understand the state of the kernel
Thanks that needs to be localized though. btw if you are going to merge your change in, you can just commit directly, no PR needed


Ref: To align with regular menus and command palette entries, this menu should use capital casing e.g. or
I proposed a fix in with just CSS but feel free to propose a cleaner way if you'd like. Unfortunately it ends up as and not . Not sure how that logic works for menus/commands.


Bug ! vscode-inno- VS Code version: Code - Insiders 1.21.0-insider (, 2018-02-09T06:14:31.856Z) OS version: Windows_NT ia32 6.1.7601 <details<summarySystem Info</summary </detailsExtensions: none Reproduces without extensions
Thanks! Very interesting. Can you somehow check which process has an open handle on ? I usually use for this.
I have the same problem. Using Process Hacker, I got this result: !. Even after closing MEGAsync, I still get this problem. ! Here's the content of the log file: The last line means .
!
When VS Code isn't running, I can move/rename this file without problems.
BTW, my OS is Windows 7 Pro x64, not "Windows_NT ia32 6.1.7601" as reported by VS Code. What's your OS?
I'm on Windows 7 Pro x86 (6.1.7601 Service Pack 1 version 7601). I haven't tested on other architectures yet.
Love it that you guys are already collecting stuff for me. I'm getting a Windows 7 image and trying it out. Can you also give me the list of extensions you currently have installed?
It works for me: Windows 10 Home(Build .rs2_release.-1834) I'm paying attention to the next updates, perhaps I can give you the needle of information.
has no extensions it seems (according to his first post). For my part, I have plenty ones: <details<summaryExtensions</summary- Bracket Pair Colorizer C/C++ C# Clang-Format CMake Code Runner cpplint Debugger for Chrome Doxygen Doxygen Documentation Generator Git History Git Project Manager gitignore GitLens - Git supercharged HTML CSS Support HTML Snippets IntelliSense for CSS class names JavaScript (ES6) code snippets jshint LaTeX Compile LaTeX Preview LaTeX Workshop latex-formatter Markdown All In One Markdown PDF Markdown Preview Enhanced markdownlint mssql npm One Dark Pro PHP Debug PHP IntelliSense PowerShell Python Unicode Latex VS Live Share vscode-icons vscode-pdf </details
I could easily reproduce in Windows 7!
Perfect :)
I am having an issue updating Visual Studio Code - Insider's Build,


The log output from the installer is shown below: Feb 12 13:40:40.605 INFO Starting: C:Program FilesMicrosoft VS Code InsidersCode - , true Feb 12 13:40:40.668 INFO Checking for running Code - processes. (attempt 1) Feb 12 13:40:40.681 INFO Code - is running, wait a bit Feb 12 13:40:41.182 INFO Checking for running Code - processes. (attempt 2) Feb 12 13:40:41.193 INFO Code - is running, wait a bit Feb 12 13:40:41.694 INFO Checking for running Code - processes. (attempt 3) Feb 12 13:40:41.706 INFO Code - is running, wait a bit Feb 12 13:40:42.206 INFO Checking for running Code - processes. (attempt 4) Feb 12 13:40:42.218 INFO Code - is running, wait a bit Feb 12 13:40:42.719 INFO Checking for running Code - processes. (attempt 5) Feb 12 13:40:42.729 INFO Code - is running, wait a bit Feb 12 13:40:43.230 INFO Checking for running Code - processes. (attempt 6) Feb 12 13:40:43.240 INFO Code - is running, wait a bit Feb 12 13:40:43.741 INFO Checking for running Code - processes. (attempt 7) Feb 12 13:40:43.749 INFO Code - is running, wait a bit Feb 12 13:40:44.250 INFO Checking for running Code - processes. (attempt 8) Feb 12 13:40:44.258 INFO Code - is not running Feb 12 13:40:44.267 INFO Starting update, silent = true Feb 12 13:40:44.267 INFO doupdate: "C:Program FilesMicrosoft VS Code InsidersCode - ", Feb 12 13:40:44.373 INFO header: Header, id: Inno Setup Uninstall Log (b) 64-bit, app id: {1287CAD5-7C8D-410D-88B9-0D1EE4A83FF2},


app name: Visual Studio Code - Insiders, version: 1048, num recs: , end offset: , flags: 0x35, crc: 0x545ea7d9 Feb 12 13:40:44.374 INFO numrecs: Feb 12 13:40:44.374 INFO moveupdate: "C:Program FilesMicrosoft VS Code Insiders", _ Feb 12 13:40:44.374 INFO Delete: "bin" (attempt 1) Feb 12 13:40:44.374 INFO Delete: "Code - " (attempt 1) Feb 12 13:40:44.425 INFO Delete: "Code - " (attempt 2) Feb 12 13:40:44.626 INFO Delete: "Code - " (attempt 3) Feb 12 13:40:45.077 INFO Delete: "Code - " (attempt 4) Feb 12 13:40:45.877 INFO Delete: "Code - " (attempt 5) Feb 12 13:40:47.128 INFO Delete: "Code - " (attempt 6) Feb 12 13:40:48.929 INFO Delete: "Code - " (attempt 7) Feb 12 13:40:51.379 INFO Delete: "Code - " (attempt 8) Feb 12 13:40:54.585 INFO Delete: "Code - " (attempt 9) Feb 12 13:40:58.636 INFO Delete: "Code - " (attempt 10) Feb 12 13:41:03.636 INFO Delete: "Code - " (attempt 11) Feb 12 13:41:03.650 ERRO Access is denied. (os error 5) I suspect that this has quite a bit to do with how this laptop is configured by our IT dept. I am connected to a local domain with standard user privileges. In order to install any software on the laptop I am required to enter my local administrator account privileges. VSCode installs and runs just fine, the issue occurs when VSCode is self-updating. Once VSCode is loaded, it reports that it has an update and I click "Install Update..." when I click on the gear icon. VSCode then downloads the update.


When it completes the download, it requests that I restart VSCode and that's when this error is generated. I've tried running VSCode as the local administrator and follow the same steps above, but the issue still persists, any help that you can provide will be much appreciated!
What is your Windows version?
Oh, it looks like is loading up that DLL! Gotta figure out how to prevent it from doing so.
I saw your commit I tried to update my VSCode application after that but it doesn't seems to works. Though, I don't have the same errors. When I hit "Restart", I got this message error: ! The differences between the old problem: There is no more the little window telling that VSCode is updating (see below) ! The log file is different: EDIT: I'm still on the same architcture. Windows 7 Pro x86 (6.1.7601 Service Pack 1 version 7601)
- Windows 10 / Version 1703 / OS Build .850
Easy, I still haven't pushed the fix.
Oh... Indeed! Sorry about this, I thought changes were effective since I didn't get the same errors. I wanted to provide a little more information not putting any pressure on this. Thanks for your involvment in this issue, I'll be more careful next time! :)
OK pushed a fix to . Guys, tomorrow there'll be a new version. The background update step to get that version, from the current one, will still fail. But background updates should work successfully from that build onwards. So, make sure you get that build from tomorrow and try to get a background update Thursday or Friday. Let me know how that goes.
Your issue is separate. Let's move our discussion over here:
Nothing failed, it has simply successfully updated. :+1: !
Alright, I uninstalled VScode yesterday, reinstalled it and today, the background update worked, just as you said. Thanks once again! o/
Marking as verified. I use background update on Windows and it doesn't fail for me.


Opening the view menu I only see them screaming at me due to their size. Can we somehow decrease their size. The native mac arrows are slightly smaller. While visual studio on windows uses a much smaller version ! !
VSCode uses Electron's toolbar if I'm not mistaken. It is basically menus in Chromium and the drop down menu in Chrome, which have arrows larger then those shown in the screenshots. So unless the toolbar can be customized, I don't think it's possible to tweak the arrow size without creating a custom toolbar. Please correct me if I get anything wrong. Thank you.
This is the custom toolbar on the windows we are currently working on. So we could customize it here imho
+1 I think the arrow could be reduced a bit


Here's a recording demonstrating Insiders (left) and previous Stable 1.74 (right): https://user- Steps: the SCM view and add a long line the width of the side bar such that the text wraps Notice how: When selecting the entire buffer, the selection expands beyond the text When selecting a subrange, sometimes the start position of the selection moves The rounded corners is generally broken: not all corners are rounded any more. This applies even for 1.74.
points to and a manual bisect points to being the first bad commit
Reverting from the change fixes the rendering problem. This diff fixes the rendering problem: The root problem here is that it is not supported that the editor background color is transparent. The class name ".monaco-editor-background" is used to render rounded corners and that stops working if it is transparent.
Thank you Tested the changes the created a PR.
Thanks for fixing. This has been on my list for weeks and I've just been, well, slammed


Type: <bBug</bwith the following code in a javascript file: the symbol "UserClient" which is missing an import is not automatically imported. if i only remove the JSDoc Comment then it is already working. if i remove the return statement it is also working. i tried it with all extensions disabled, nothing. please fix this. VS Code version: Code 1.72.2 (, 2022-10-12T22:15:18.074Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ lit-html1.11.1 vscode-html-css1.13.1 lit-lang0.0.7 prettier-vscode9.9.0 csharp1.25.0 powershell2022.10.0 vscode-xml0.22.0 lit-plugin1.2.4 markdown-preview-enhanced0.6.3 blueprint3.0.0 markdown-all-in-one3.4.3 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Please share a minimal, self contained project that demonstrates the issue
Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our . Please take the time to review these and update the issue. Happy Coding!
note: is just a bundled version of the lit-html plugin. the project i'm using works has the requirement to work without any kind of build so we bundled the only npm dependency it had into this file. still looking for a better solution though...
I'm facing the same issue. and get executed as expected, but seems to not working. To reproduce, just open a TS project, set the to the option, remove an import from any source file and save. The imports gets organized but the missing imports doesn't get imported.
I even noticed that it still works under certain circumstances. like in my demo project, if you remove the JSDoc comment. something in the code context seems to be killing the import feature. but manual import still works (like with hovering the item, quick fix, import)
any updates, info requests, anything? did you find a lead, can you work on it?


can you fix it?
I can confirm this issue, I can trigger the autocomplete for the import with either ctrl+space or ctrl+. however it is not automatically on save even with enabled. This feature was working for me some time ago, but I can no longer get it to work.
Any fix yet?
Changing the order to solved the problem for me.


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --This could include platform specific instructions. Curious to know which platforms we're talking about here... Windows for sure but what else? Does Raspbian ship git?
Hi, I would like to work on this please assign this to me.
thanks! We cannot assign you as you are not a member of this issue, but please feel free to submit a PR. The relevant code is here:
I can take this up if it's not already done. Could you elaborate on what new step needs to be ?
hello guys, i'm really trying to get started in contributing to open how i get started here?
Hello this is my first time contributing to an open source project and I'm willing to work on this issue. I just set this repo up on my machine and its working. I had a look at the file you've shared and there are conditions for few steps which checks if git is missing. So, I tried simulating the inexistence of git just by disabling it in vs code settings. Is that fine? And also, should there be a button which says "Install Git"? If yes, what should it be linked to? !
We can use I recommend testing this by fully removing git if at all possible, otherwise there my be unexpected behaviors when a new users is actually running this for the first time.
Is this complete, or I can still work on this?
I am not aware of any work done here.
Could you assign it to me? I would like to work on this quickly. Edit I guess, Only members can be assigned. So, I will open a PR and link to this issue.
Hello, I'm sorry I should've kept you updated but I've made those changes and I just have to test it out by uninstalling git.
I have tested with uninstalling git. Can I take this?
Omg I just did that to push. What do we do?
Just tested this on Windows, and the "Install Git" item is marked as ticked when you click on the "Install Git" button regardless of whether you have actually installed Git - is this expected?