jiebi/CodeConvo huggingface dataset:
Code change:
private _sortByLabel = true; private _autoFocusOnList = true; private _keepScrollPosition = false; <del> private _itemActivation = this.ui.isScreenReaderOptimized() ? ItemActivation.NONE /* https://github.com/microsoft/vscode/issues/57501 */ : ItemActivation.FIRST; </del> <ins> private _itemActivation = ItemActivation.FIRST; </ins> private _activeItems: T[] = []; private activeItemsUpdated = false; private activeItemsToConfirm: T[] | null = [];

Related discussion:
text: 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.
Code change:
private _sortByLabel = true; private _autoFocusOnList = true; private _keepScrollPosition = false; <del> private _itemActivation = this.ui.isScreenReaderOptimized() ? ItemActivation.NONE /* https://github.com/microsoft/vscode/issues/57501 */ : ItemActivation.FIRST; </del> <ins> private _itemActivation = ItemActivation.FIRST; </ins> private _activeItems: T[] = []; private activeItemsUpdated = false; private activeItemsToConfirm: T[] | null = [];

Related discussion:
text: 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.
Code change:
private _sortByLabel = true; private _autoFocusOnList = true; private _keepScrollPosition = false; <del> private _itemActivation = this.ui.isScreenReaderOptimized() ? ItemActivation.NONE /* https://github.com/microsoft/vscode/issues/57501 */ : ItemActivation.FIRST; </del> <ins> private _itemActivation = ItemActivation.FIRST; </ins> private _activeItems: T[] = []; private activeItemsUpdated = false; private activeItemsToConfirm: T[] | null = [];

Related discussion:
text: Does it make sense? Yes, that is correct. actually, your visual explanation has helped me understand the entire experience better. I initially thought that there was no cursor in the text field at all while the user was typing.
thanks a lot for your comments! I really want to sit down and play with aria-live some more based on your idea. Considering that this issue is pressing, I've made a small change to get the placeholder to be read out.
happy to test that change when it becomes available in an insiders build, or remotely with you in case you want earlier testing. for my idea to work, it would require some changes in keyboard behavior as well, and careful testing so that we don't break current user expectations around a widget which is critical for some customers. feel free to reach out if you need additional input.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
I did some testing using the latest insiders build and NVDA Results with screen reader mode on: Placeholder text is announced when the widget receives focus. When typing in the text field, the number of results is announced by NVDA but not the highlighted option. This can be a productivity killer. I believe the announcement of the highlighted option is the most important piece of information while typing. the number of results is irrelevant at this point. It becomes important when the user starts to navigate with the arrow keys, and at that time the screen reader takes care of it. Screen reader mode off: When the widget receives focus, the number of results is communicated by NVDA followed by the announcement of the quick input list and the highlighted element, but the placeholder text is not announced, likely because the "combobox" portion doesn't have focus. when typing, NVDA announces changes in the highlighted option in Braille and speech as expected.
Code change:
private _sortByLabel = true; private _autoFocusOnList = true; private _keepScrollPosition = false; <del> private _itemActivation = this.ui.isScreenReaderOptimized() ? ItemActivation.NONE /* https://github.com/microsoft/vscode/issues/57501 */ : ItemActivation.FIRST; </del> <ins> private _itemActivation = ItemActivation.FIRST; </ins> private _activeItems: T[] = []; private activeItemsUpdated = false; private activeItemsToConfirm: T[] | null = [];

Related discussion:
text: Version: 1.77.0-insider (user setup) Commit: Date: 2023-03-23T10:21:45.873Z 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
Closed Verified the issue in latest environment: Version: 1.78.0-insider (user setup) Issue is fixed. Hence closing the bug. please find attachment for reference. https://user-
Code change:
this.element.ariaRoleDescription = localize('terminal.integrated.accessibleBuffer', 'Terminal buffer'); _instance.onDidRequestFocus(() => this.hide(true)); this.updateEditor(); <del> this.add(this.editorWidget.onDidFocusEditorText(async () => { if (this.element.classList.contains(ClassName.Active)) { // the user has focused the editor via mouse or // Go to Command was run so we've already updated the editor return; } // if the editor is focused via tab, we need to update the model // and show it this.registerListeners(); await this.updateEditor(); this.element.classList.add(ClassName.Active); })); </del> // xterm's initial layout call has already happened this.layout(); }

Related discussion:
text: Type: <bBug</bthe settings like below: : new terminal via ctrl+` from terminal input. Pressing Shift+Tab moves to the terminal buffer. Shift+Tab should be passed to terminal as an input key. The focus needs to remain in the terminal input field. We need when cycling back through shell auto-suggestion or ipython completion. VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-19T05:34:51.441Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (90)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.1.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 dscodegpt2.1.14 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.19.1 gitlens14.1.1 EditorConfig0.16.4 prettier-vscode9.19.0 vscode-google-translate1.4.13 codespaces1.14.12 copilot1.97.271 copilot-chat0.5. remotehub0.60.0 vscode-github-actions0.25.8 vscode-pull-request-github0.68.1 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.1 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11.
Code change:
this.element.ariaRoleDescription = localize('terminal.integrated.accessibleBuffer', 'Terminal buffer'); _instance.onDidRequestFocus(() => this.hide(true)); this.updateEditor(); <del> this.add(this.editorWidget.onDidFocusEditorText(async () => { if (this.element.classList.contains(ClassName.Active)) { // the user has focused the editor via mouse or // Go to Command was run so we've already updated the editor return; } // if the editor is focused via tab, we need to update the model // and show it this.registerListeners(); await this.updateEditor(); this.element.classList.add(ClassName.Active); })); </del> // xterm's initial layout call has already happened this.layout(); }

Related discussion:
text: python2023.12.0 vscode-pylance2023.7.30 jupyter2023.6. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.301.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.80.2 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.7.1717 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.15 vscode-serial-monitor0.10.0 vsliveshare1.0.5873 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.2 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.90.0 r-debugger0.5.4 java1.20.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.23 latex-utilities0.4.10 chatgpt1.1.2 cmake0.0.17 errorlens3.12.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.52.0 vscode-java-dependency0.23.0 vscode-java-pack0.25.12 vscode-java-test0.39.0 vscode-maven0.41.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
related this also reproduces in stable VS code
We're going to remove the keybinding altogether as it should enter the buffer when toggle tab moves focus is enabled and not (as designed) without that
Changing the keybinding could throw users off,
Code change:
this.element.ariaRoleDescription = localize('terminal.integrated.accessibleBuffer', 'Terminal buffer'); _instance.onDidRequestFocus(() => this.hide(true)); this.updateEditor(); <del> this.add(this.editorWidget.onDidFocusEditorText(async () => { if (this.element.classList.contains(ClassName.Active)) { // the user has focused the editor via mouse or // Go to Command was run so we've already updated the editor return; } // if the editor is focused via tab, we need to update the model // and show it this.registerListeners(); await this.updateEditor(); this.element.classList.add(ClassName.Active); })); </del> // xterm's initial layout call has already happened this.layout(); }

Related discussion:
text: though is wondering if we can treat this like a widget with results/ input and allow moving between the two with keybindings consistent with
Shift+tab is still going to the workbench even when I remove that keybinding and have tab moves focus mode off
We now allow using or to go to the terminal accessible buffer instead. I think it makes sense to remove as a keybinding next iteration if we agree that makes sense and The only downside of that would be users might already have in their muscle memory.
If we cannot resolve the synchronization issue with autocomplete and shift +Tab, I am in favor of removing the key-binding. there are worse things than retraining mussel memory.
Yes, and I just discussed, and we agree it can be removed this iteration.
We will also remove the tab index
I cannot reproduce the original issue in stable (either 1.81 or 1.78). What are the steps to verify?
Sorry, to verify, focus a terminal with screen reader mode enabled. Use . the accessible buffer should not open.
This does input and no longer shows the a11y buffer, but the event also bubbles beyond and moves the focus to the panel title incorrectly: !
Guessing we need to do something with tabindex that must've been removed in order to get this to work
I think it would be either shift+tab needs to be specially handled in or we should handle it and cancel the event in the custom key event handler.
not sure how this was working before. I dug through commits and tried reverting this one, which didn't help.
Code change:
"html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

Related discussion:
text: I love VS Code, But please, don't make that option default : mirrorCursorOnMatchingTag it's a nightmare Thank's
can you please share more detail about what behavior makes it so bad for you that you had to change the setting?
/needsMoreInfo
Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our guidelines. Please take the time to review these and update the issue. Happy Coding!
Hey I agree with with this one here. I first came across this new feature today after updating VSCode, and after some searching, saw the setting & feature mentioned over at IMHO - This should be disabled because it feels unnatural to select an HTML tag after it's initially created and want my IDE to automatically create multiple cursors on it's closing tag by default. I'm more likely to go to an opening tag and add attributes (or like when I'm working on an Angular/React project, add directives, inputs and outputs to my components) than want to have multi-cursors to rename the component/tags (which if needed, can be done with the Ctrl+D key binding anyway). Took a few minutes of head scratching to figure this all out, and seems like I'm not alone on this one. I'd say it's one of those things that could be enabled if needed, but disabled by default. :)
I might have a narrow use case here but I use to write Angular code. These multi-cursors on HTML tags completely ruined my ability to edit the file. I tried copying the current line with and it copied both the line where my cursor was and the line with the matching HTML tag. I didn't notice this until I tried pasting with and it pasted both the line I copied and the line with the matching tag a couple lines above that. I noticed it changed more of the file than I intended but it took me multiple operations before I realized multi-cursors were the culprit. I tried using to open a line below my current line and it two lines because there were two cursors. Then I tried using to append to the end of a line (after an HTML tag) and it appended only on the first cursor (the opening tag), which meant I couldn't append to the end of the line. Thank you for adding the setting because this was infuriating to me.
Code change:
"html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

Related discussion:
text: I couldn't understand how my vim plugin was so horribly broken. I could probably complain to the vsvim project that they should disable this setting when installing the extension but I figured I might as well throw my use case into this issue first.
Instead of mirror cursor on matching tag (which conflicts with vsvim for me), have some feature which only changes the matching tag name. I don't want to add to the closing div tag (as it just happened to me). Also when using vsvim, and you press to open a new line, it opens a new line in both locations.
While I like the idea of being able to edit start/end tags at the same time, the way mirrorCursorOnMatchingTag works currently has some flaws that are really easy to trip over. I noticed it has special handling for typing a space in the start tag which is nice, but there are some other cases that can cause problems. For example, pasting - currently if I try pasting an attribute into a bare start tag, my end tag gets the attributes too, which I don't want and have been frustrated by a number of times. There's also an issue with getting double comments when toggling comments for a tag that starts and ends on the same line. A third issue is that it doesn't seem to work when making a selection with the mouse (either by double clicking the start tag or by dragging a selection in the start tag), which is my primary way to rename tags. Suffice to say, my initial impression is that this feature is buggy and doesn't completely accomplish what it was meant to do, and so I don't think it should be a default option until it can work more smoothly and not cause disruptions to my regular editing.
I just wanted to change the closing tag of a specific element. Since this feature enabled itself after the last update unawares to me, I could not change the tag because the feature also changed the opening tag that element, and also other identical strings in the file. I had to google myself silly just to turn it off. Then, when I tried to turn it back on to test it, it didn't work at all. I don't see any productivity benefit with this feature, at least not in the current unreliable state. The use cases where I'd want to turn if off far outweigh the productivity benefit that I might glean from having it on by default.
Code change:
"html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

Related discussion:
text: It's irresponsible to introduce and enable a new feature by default. I wasn't pleasantly surprised at all.
As mentioned in some comments above, I don't mind the feature but the fact that there are two cursors simply because the cursor is inside and next to the tag name is a bit weird in my opinion. I mostly work using Angular and it's a bit frustrating when code is pasted in the opening tag and gets pasted in the closing tag too. Why not make the feature that the double cursor appears when any text of the tag name is selected (i.e. highlighted)? If I explicitly want to change the tag name I would then simply double click tag name name type therefore changing the opening and closing tag. ! If for some reason I select part of the opening tag name, the closing tag name gets selected too (and vice-versa). !
As we were in the comments, it is wonderful that VS Code allows a plugin mechanism so that I can have extensions that make all sorts of nifty things happen when I edit, such as adding matching tags, inserting tags from abbreviations, or whatever. That's what extensions are for. But the VS Code made two big mistakes here. First they turned on a a feature automatically that should be an extension. It fundamentally changes how the editor operates. I make some changes here, and I don't expect, without some further action on my part, that it will at the same time make changes over there. I see flashing cursors everywhere while I'm trying to edit it, and things I did not touch suddenly get modified. An editor is not for surprises, especially when it comes to modifying content. It was bad enough turning this thing on by default, but the other horrendous mistake was pushing out this half-baked, ill tested feature on us. It has huge bugs, which have been reported already by many—see for example . If I have an element that has attributes, when I select and delete the attributes this new buggy feature selects and deletes content outside the closing tag, completely corrupting content; removing essential, unrelated content; breaking the document; and losing the information. VS Code is becoming my go-to editor, and it is becoming beloved by a huge community. Don't squander this support by starting forcing half-baked and ill-tested gadgets on us.