jiebi/CodeConvo huggingface dataset:
The issue was introduced by this PR where becomes extremely slow
I had the same issue and setting to does the trick.
When I just hit the enter key on a bash prompt it takes about 4 seconds for the prompt to return. I ran process monitor and noticed many many (maybe over a hundred) instances of being spawned to run the shellIntegration- script.
Any idea where this ticket is tracked? Every reference to the issue is closed marking duplicate.
Closing an unfixed issue that everyone have ? I don't get the point
I closed this accidentally, have reopened.
worked for me !
Hey guys I'm having the same issue. Running a single is taking over 15 seconds to complete the command. After disabling , bash looks way better
The problem seems to be related to The issue happens also if I start (outside VsCode) my bash thus (same as VsCode does for its terminal): Each time the prompt must be shown (eg, after simply pressing the Enter key) a delay of about two seconds happens. Most of the delay is caused, it seems, by the function In particular, commenting out the line 178 seems to alleviate good part (not all) of the delay. Edit: More specifically, the culprit seems to be If I change the line 109 from to (effectively forcing "the switch to the faster function"), the problem goes away. (BTW: the faster function seems to have a bug of its own, it produces an extra prompt!)
Process monitor screenshot shows it re-running this over and over 89 times when I press enter at the shell prompt "C:Program FilesGitbin..usrbin" --init-file "c:UsersarthuAppDataLocalProgramsMicrosoft VS Coderesourcesapp/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-" !
Disabling is another workaround that improves the delay for me.
Hello Guys, This setting worked for me.
This helped me, thanks!
will move you to the old backend stack which significantly reduces the functionality/capabilities of the terminal. shouldn't do anything. is the right workaround for now, expect a fix soon though
what caused so many bash invocations when shell integration is enabled?
we started reporting the bash prompt in order to better position shell integration markers and understand the prompt.
Apparently printf is just extremely slow on git bash
I had this terminal slowdown problem, in git bash, and found setting fixed the problem - the terminal was back to being fast. However, after the last, or recent, insiders update, even with that setting set to , the terminal is slow again - and it's showing the icons, etc. like it is ignoring this setting: ! !
you probably just didn't restart the terminal. This is now fixed and will come in the next Insiders and likely 1.90.1
Actually, I had the shell integration disabled for the last several insiders updates, so it has been off for a while. Terminal windows have been created and closed many time since. For whatever reason, when launching VSCode and the terminal session was restored, this last time, the integration feature was ignoring the flag. I terminated the terminal and started another, and the integration went away again. So basically the integration flag was ignored when the terminal session was restored. I just did a quick test of quitting VSCode, with a terminal window open, then relaunching, and the integration was still disabled. Unsure what happened. Guessing, also, you type-o-ed the version? I am already running 1.91.0 insider !
what happened was the terminal was restored which re-creates the process after vscode starts with the original environment, args, etc. No the next insiders build on Monday and v1.90.1 (stable)
when will be the next minor update, not the insider build so this terminal slowness is resolved?
FWIW, I can also observe the prompt's slowness on Linux (bash 5.1.16(1)-release on Ubuntu 22.04.4 LTS) on the order of a half-second or so (still annoying but bearable). looks like a temporary workaround for Git Bash only; will we fix the underlying cause of the slowness?
I also observe this to be slow over linux using an ssh remote. It's much slower if I have a starship prompt enabled (4s) and around 1s if I have the default debian prompt.
I have this issue (Win 10, git bash). The suggested workaround of disabling shell integration then restarting terminals worked for me.
Also having this problem. Disable terminal integration worked for me too. (Win 11, Git bash).
I re-enabled terminal integration with the latest Insiders - ! and it the problem seems to have been fixed. For me at least.
Yes, it's been fixed in insider's already.
Perfect solution
When is the release date for the VSCode stable one?
no exact date, but probably later this week
, Turning off shell integration only sorta helped me out. It does return a result slightly faster, but it does not return the prompt back for 4 seconds or so, but only with python poetry workspaces/folders opened. This slowness goes away if I don't have a workspace/folder open, a non-poetry python one, a javascript one, etc. There's now a '(packagename-pythonversion)' at the top of my prompt when I open a python poetry folder and that seems to be taking forever to generate after each command. Definitely wasn't happening before my last update. This seems like a separate issue? Or is it related somehow? Happy to open a separate Issue if needed.
I don't know if this is the same as your issue but I've found that, if I already opened a terminal in a workspace before changing the setting, I had to kill the terminal for that workspace and open a new one so it would be initiated with the updated setting.
Yes. With the feature disabled, issue does not happen . But the feature will not work also . I can live without that feature but I like it. It makes my IDE look smarter. It's strange. I remember the feature was there earlier without any issue.
Was the fix included in 1.90.1? The shell integration is still too slow even after I updated to 1.90.1. It still takes over a second for all those bash commands to run every time press the enter key at the terminal. I have to keep it off to keep my Windows git bash terminal usable. It seems like it takes around a second and a half to get a new prompt with that setting on. Is this expected?
I just updated to this version: Version: 1.90.1 (user setup) Commit: Date: 2024-06-11T21:01:24.262Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Windows_NT x64 10.0.
it should be fixed yes, can you run and paste in the results?
$ for i in {1..10}; do time _vscreport_prompt; done real 0m0.236s user 0m0.045s sys 0m0.092s real 0m0.194s user 0m0.045s sys 0m0.076s real 0m0.210s user 0m0.030s sys 0m0.122s real 0m0.217s user 0m0.015s sys 0m0.152s real 0m0.216s user 0m0.061s sys 0m0.138s real 0m0.245s user 0m0.045s sys 0m0.123s real 0m0.202s user 0m0.015s sys 0m0.091s real 0m0.212s user 0m0.061s sys 0m0.091s real 0m0.230s user 0m0.000s sys 0m0.153s real 0m0.212s user 0m0.045s sys 0m0.108s
It seems like it's taking a long time to parse the prompt. My git bash prompt is user MINGW64 /c/path/to/dir (master), where the my /c/path/to/dir is a 29 character path. But sometimes it's a lot longer. Does a longer path make it slower?
When I cd to a 135 character path, and try to time it it just prints 633;D;0: $ time vscreportprompt 633;D;0 $ vscreportprompt 633;D;0
those numbers aren't too bad, but regardless I think we need to rethink how we're doing this prompt reporting feature. I'm going to stick it behind a setting in so it's just disabled completely by default.
This is still unreasonably slow, IMO. If I'm running a shell with the extensions the shortest possible interval between two commands seems to be over 700ms on my machine: ! Running without the shell integration, it's closer to 250ms, and that may only be because that's how fast I can press the ⇧⏎⇧⏎ keys: ! Despite the improvement over 1.90.0, I still feel like I have to disable the shell integration. It's 2024. Having to wait a perceptible amount of time just for the terminal prompt to re-appear feels like a huge regression to 1980s computing. Is my floppy drive trying to seek to a specific sector?
v1.91 which I think is being released today includes the changes I mentioned in , disabling the prompt reporting stuff completely (for the stable build): !
I'm running 1.91.0 (insiders) and I still see a significant delay between prompts (on windows, using git-bash terminal). Turning the shell integration off speeds it up quite a bit.
it's only disabled in the stable build. Insiders keeps the slower code as it provided reliability improvements and the plan is to optimize it soon.
While v1.91 does seem to improve the delay, there's still a noticeable delay for me so I'll be sticking with the option disabled.
<!-- 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. --Hello, we have been recently testing out our extension for accessibility bugs, and we believe we may have found one directly linked to vscode. The extension we are using is Bridge to Kubernetes. Does this issue occur when all extensions are disabled?: Yes VS Code Version: Visual Studio Code Version 1.73.1. (user setup) OS Version: Windows 11 Version 21H2 (OS Build .376) Steps to Reproduce: on NVDA/JAWS. Visual studio code application and setup Bridge to Kubernetes extension. cluster config file and load 'stats-apo' project. 'Ctrl+Shift+P' open command palette in View menu. 'Bridge to Kubernetes: Configure' and press enter. using down arrow key to select 'stats-api' in connect to kubernetes (1/4) stage and press enter. '3001' in connect to kubernetes service: stats-api (2/4) stage and press enter. whether NVDA/JAWS is announcing the given placeholder text at edit field or not.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.73.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Hi The bug still exists with the new vscode version. I edited the original post. Thanks!
I think you just worked on improving the accessibility of the quick pick - thoughts on this?
A11yMAS; #A11yTCS; #A11ySev2; #DesktopApp; #Win32; #Visual Studio Code Client; #BM-VisualStudioCodeClient-Win32-Aug2022; #WCAG1.3.1; #Element:Placeholdertext; #AILimited; #JAWS; #NVDA;
have you looked into the feasibility of supporting this?
Sorry I'm not sure I totally follow here.
Just to make sure, can you attach a gif? /gifPlease
Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, files are preferred as they are displayed inline on GitHub. You may find helpful as a browser-based gif recording tool. If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording ( in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue. Happy coding!
from the above description, I believe what expects is for the placeholder text to be read before the selected item is. From my testing though, that is working already (I tried and
Thanks for the comments and I will try and get a gif for you folks in the upcoming days!
sadly gif does not record audio. I will record a video and send it to you internally.
video uploads on GitHub issues work now so you can always attach here :)
I have attached a video below! Basically, the place holder text should be read with NVDA. The accessibility folks have flagged this as a bug. Thanks! https://user-
do you have Accessibility mode turned on? Just checking. You should have gotten a notification about it.
you can turn that on with
Let me test that today thanks!
where do I find ?
and search for . The alternative way would be to run the command via the command palette
Thanks for this it was set to auto. I will turn it to on and try again
It is still not pronouncing the text in the edit field. Would you classify this as a bug or is this just a part of VsCode?
I can reproduce the issue - I'd expect the placeholder text to be read before the selected item is, but that does not happen.
Example: In a multi root workspace, run . I'd expect it to read to me: "Select current working directory for the new terminal"
Logging shows that the quick input's aria label is correctly set. After that though, when an item is selected by default, its aria label takes precedence
Perhaps when is true, we could not select an item by default so that the placeholder text will have focus every time?
thought that was the behavior today? Just opened the Command Palette... focus is in the input: <img width="830" alt="image" src="https://user-"
I mean when you run a command that opens a quick pick such as !
commenting out this code fixes it
so I think we need to check there if and not focus
Looks like this use to be reported in
! odd I don't repro with that command you have... wonder if we have a conflicting setting. Also VoiceOver did read out the placeholder in this case.
for me, the placeholder is not read in most cases (but it is with the changes in the PR)
my repro steps were when in a multi root repo, run that command. the first quick pick placeholder isn't read
Hi and I see this as moved to the backlog. Do we have a rough date in which this could possibly be looked at again? I plan on telling the testers that you two are looking at the bug. Thanks!
I did it in "holiday mode" as a lot of us are disappearing for the holidays. I'll leave it on January
Thanks for the update that totally makes sense. I will let the testers know. Happy holidays!
do you see a way to do this? it's not clear to me where the item is getting focused
is open to testing the PR once it is available
We'll try to fix this in February with the following read by the screen reader via : placeholder of input box (note this doesn’t logically have to be the placeholder, it could be an aria label set somewhere) number of items in the list the label of the highlighted item in the list (aka the first item in the list)
I just discussed with and he says "I need an ARIA expert because I can’t get this to work nicely. is what we use today on the quick pick input box. That points to the focused item in the list. This is needed because true focus always stays in the input box. The problem is that if an element has AND the is ignored. I’ve tried a few other solutions and haven’t had luck, unfortunately. Looking for creative solutions" might you have suggestions here?
Just to provide an update... After chewing on the problem yesterday, my best idea is to try to mirror this design pattern as much as possible: Applying it to the quick pick means making the following changes: in a11y mode, we do not focus any of the items in the list. Doing this, we can easily ensure that the placeholder is read out because aria-activedecentant won’t be set yet in a11y mode, When the user types something in the input box, aria-activedecendent is removed and we remove the "active" state of the elements (thus focus goes back to the input) When pressing down the first element is highlighted. aria-activedecendent is set on the inputbox pointing to that item. The item gets read out. Nothing new here. While this pattern is fine, it's not really what I want because the QuickPick isn't really a combo box (though I'll admit it's close). I’m sad because I would rather not have specific a11y mode behavior here… but this is the best I think we can offer with my ARIA skills. Tl;dr: I need a solution for reading the placeholder of the quickpick input box first and then read out the first highlighted item in the list (the aria-activedecendent)
Hi team. I’m reading the thread and I’m probably missing something but I’m concerned that there is perhaps a misunderstanding about how the quick input experience works in general and the particular issue of the Bridge to Kubernetes extension. Perhaps I’m missing the problem, but the quick input list works well for me. Here is an example: the command palette by pressing CTRL +Shift +P a. NVDA announces the label and placeholder text for the editable field as follows: “Type the name of a command to run. combo box has auto complete editable Press 'Enter' to confirm your input or 'Escape' to cancel”. type git, for example, and select the Git clone command with the arrow keys and Enter. a. Upon selecting the command, focus returns to the editable section and NVDA reads the prompt as follows: “Provide repository URL or pick a repository source. combo box has auto complete editable Press 'Enter' to confirm your input or 'Escape' to cancel Provide repository URL or pick a repository source. blank”.
use the arrow keys to select the option to clone from remote sources and press enter on it. a. Upon pressing Enter, focus returns again to the editable field and the prompt is read again: “Repository name (type to search) combo box has auto complete editable Press 'Enter' to confirm your input or 'Escape' to cancel Repository name (type to search) blank”. I wouldn’t expect this to behave any different. The only instance where I have observed a different behavior is with the Bridge to Kubernetes extension where, upon selecting the connect command, for example, screen reader focus seems to jump directly to the list instead of the editable portion which is the standard behavior, maybe because aria-activedescendant is set at a time when it shouldn't? why you would like the placeholder text and the first highlighted item to be read together? I understand the placeholder text as the label for the editable field, therefore it is relevant only when the editable field is focused. By focused in this context I mean that it has screen reader focus, not keyboard focus. When we manipulate aria-activedescendant we are communicating the screen reader to focus on a different control, therefore the label of the control with focus shouldn't be read. The label of the list portion is "Quick Input list", and that is actually the hint that we are now exploring the list of options. I fully agree that we should stay away from an A11Y exclusive mode as much as possible.
because this is the behavior of a sighted users today. They are able to see the placeholder in the input box and the first item in the list is already focused (using ). This allows a user to be shown the quick pick and be able to hit to accept the first item in the list. Putting the "quick" in "quick pick". Today, users of a11y mode via the setting have a different experience, which is what you describe... no item is initially focused and a user in a11y mode must hit down arrow to get to the first item in the list.
My wish is that we could have the same experience for users of a11y mode and not... but my research above, albeit not expert level, has given me the perspective that it's just not possible... and that it would be easier to fix the bug you call out which can be simplified to: "When we chain quick picks we need to remove on any item if one exists so that the 2nd quick pick reads the placeholder"
Thanks I think I understand now. Since this is really not a combobox, I would then suggest a change to the way this works from a keyboard and screen reader perspective. Please take this as a general idea which could be significantly refined or completely abandoned. and Shift +tab can be used to move focus between the edit field and the list box. Tab works now, but shift +tab doesn't return focus to the text field. Visual keyboard users can press Enter in the text field to trigger the first element in the list which is selected. Blind screen reader users can tab to the list to hear / read the element selected and press enter from there. text in the text field changes selection visually and updates an aria-live region with the selected item in the list. In a way it is better than manipulating aria-activedescendant because the text is still editable. note: It should be a visually hidden live-region which will only contain the visually highlighted item at a given time. while focus is in the list filters the list as it does now but doesn't update the aria-live region because screen readers are tracking ffocus in the list itself therefore there is no need to announce anything. focus is in the text field, pressing down arrow changes selection in the list and moves focus to the list itself. quick pick changes resulting from selecting an option, we reset focus to the edit field so that the placeholder is read. Screen reader users can then tab to the list to hear the selected item / navigate, or start typing in the edit field. remove the combobox role from the text field because we agree it is not a combobox. note: As a blind screen reader user myself, I don't know how the experience looks / feels like from a visual perspective.
For example, I don't know if sighted keyboard users can edit the text as they type, or if there still an insertion point visible in the text field as ones navigates in the list with the keyboard as it is now.
I think we are on to something here... Thanks for your input. It sounds like, from what I can tell, you are suggesting we drop aria-activedescendant usage from the input box and go with your alternative. I'm intrigued by this idea. I have a couple of follow ups mostly because my ARIA skills are quite low: you: Could you explain the difference between these two approaches? How are they represented differently via a screen reader? Just to confirm, yes, the inputbox that currently has is still editable and should be editable. We want users to be able to continue typing to further filter the list... just like a combobox. said: Today, when you type a character, the active item in the list becomes the first item in the list. I would imagine we would still announce via if that item isn't the one the screen reader user is on? clarify what you said here: Yes. Visual users are able to see a cursor in the input box that they can move left to right as they choose and edit the text in the box while an item in the list is active (again, similar to the combobox example I linked above). This works today because true focus is entirely kept by the input box. "fake focus" or what we call "the active list item" never actually gets browser focus, it just appears "focused" or "active" or "highlighted" to the user compared to the items in the list.
Hi ! quoting you: Aria-activedescendant overrides DOM focus. It means that, as soon as we add the property, screen reader focus goes to the list and screen reader no longer track the cursor in the text field. If we use an aria-live region however, changes in selection can be announced while focus is maintained in the input field for the user to edit. In this way if an element is selected in the list by default, we can announce that element and the placeholder text will be read by the screen reader due to the focus event. We may not be able to fully control the order in which both events are read, but that's a lesser problem in my opinion.