Change:
"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "b07f2f0f42a1483cd2e5ec8fa3c77ebaa0507069" </del> <ins> "commitHash": "047f474eabcbffc85cca8bb0fdbe8650afa5bf33" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "22.3.11" </del> <ins> "version": "22.3.13" </ins> }, { "component": {

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- 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.80.0-insider (user setup) OS Version: Microsoft Windows Operating System Version 10.0..1778 Steps to Reproduce: This issue is related to to solve a bug related to reading lines word by word where there are and signs in the editor with screen readers. This bug was fixed in Chromium 111 / Electron 24. Could it be possible to backport this fix to the Chromium version used in the current version of electron/VS Code? Nowadays, working with HTML or XML is really tedious and annoying. For example, imagine this line: Starting from the beginning, what the screen reader reads to me when I press ctrl+right arrow is the following: (col 3) As you can see, the mechanism that looks for the boundaries between words is not taking into account the < and signs when pronouncing each one of them. This is what has been solved in this bug. Thanks in advance! cc
this is the backport issue that we discussed.
Thanks for linking the CL, I will backport the fix.
thank you very much for the fix do you mind verifying in VS Code insiders from Wednesday if this is indeed fixed for you. Thank you
<!-- 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!
and I just tested it and it's working perfectly! Thanks guys, I really appreciate the effort to make the backport, and the speed with which you did it :)
thanks for letting us know

Type: <bBug</bHelp menu. click the vscode window title to maximize window. to open Help menu again. VS Code version: Code 1.72.2 (, 2022-10-12T22:16:26.920Z) OS version: Linux x64 5.10.0-18-amd64 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (12)</summaryExtensionVersion ------ vscode-eslint2.2.6 svg-gallery2.1.0 xml2.5.1 gitlens12.2.2 EditorConfig0.16.4 prettier-vscode9.9.0 vscode-react-typescript1.3.1 svg1.4.20 vscode-docker1.22.1 csharp1.25.0 color-highlight2.5.0 bash-beautify0.1.1 </details<!-- generated by issue reporter --
Related:
Confirmed on CentOS 7
Are you running with custom or native titlebar ? Does this issue persist with latest stable ? I am unable to repro on Ubuntu 22.04 on Wayland.
Ignore my crash dump; it is the libcrypto issue again, rather than something to do with the menu. is the menu issue still occurring for you on the latest Stable 1.74.1?
Yes, The menu issue is still occurring on the latest Stable 1.74.1. I don't know whether the issue is related to my OS and Desktop environment. OS: Debian 11 bullseye Kernel: x86_64 Linux 5.10.0-19-amd64 DE: GNOME 3.38.4 GTK Theme: Adwaita-dark [GTK2/3] I found the issue comes from Electron framework v19 (on my PC environment). It cannot be reproduced on Electron framework v18.
do you have a system wide installation of Electron ? Given you are on Debian 11 is Wayland the default ? In that case, can you try running with ?
I don't have a system wide installation of Electron. I ran the sample app on Electron v18 () and Electron v19 () You can get the bug screen records from here: I installed the desktop environment from gnome-core package (). I don't have much knowledge about Wayland, but I think Wayland is the default.

I cannot run code command with "--ozone-platform=wayland --enable-features=WaylandWindowDecorations" auguments !
Thanks for the recordings and confirming the issue with Electron. Can you run the Electron samples with and see if the issue persists ? Also please test with Electron 22 since that is the latest stable. You can ignore the warnings printed, the flags are passed to the runtime. Does the issue persist when running with these flags in VSCode ?
Below are the results: issue is still occurring on the latest Electron v22 (without the flags) issue is fixed on the latest Electron v22 (with the flags), but the layout will be broken. The issue is still occurring on the latest VSCode v1.74.1 (with the flags)
Thanks again for the results, VSCode will update Electron 22 next iteration , we close this issue once that happens. As for the broken layout with Electron 22, I will open a separate upstream issue to track it.
Reopening because Electron 22 was reverted for the March milestone.
this looks like electron/electron, so current Electron v22 won't fix it for X11. I've got a PR up to fix that issue, and will probably backport to Electron v22 once it's merged.
Thanks :)
<!-- 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!