Change:
const fontFamily = this.getInputEditorFontFamily(); const fontSize = this.getInputEditorFontSize(); const lineHeight = this.computeLineHeight(fontSize); <del> // We respect the configured `editor.accessibilitySupport` setting to be able to have wrapping // even when a screen reader is attached. </del> <ins> // We must respect some accessibility related settings </ins> const accessibilitySupport = this.configurationService.getValue<'auto' | 'off' | 'on'>('editor.accessibilitySupport'); <ins> const cursorBlinking = this.configurationService.getValue<'blink' | 'smooth' | 'phase' | 'expand' | 'solid'>('editor.cursorBlinking'); </ins> this.setPlaceholderFontStyles(fontFamily, fontSize, lineHeight);

Discussion:
Issue Type: <bBug</bIn the Windows start menu, type "cursor blink rate" to search for the cursor blink rate setting. Configure this setting to be "None" in order to disable text input cursor blinking. Try out various places where you can input text in VS Code. Some honor the setting and some do not. Here are examples of places that do not honor the setting: In the Git view, click the Message text input to write in a message. The cursor will blink here. Debug a process and click the command input in the "debug console". The cursor will blink here. Here are examples of places that honor the setting: In the file view, click the "new file" icon to get a text input field where you can enter the filename. The cursor will not blink here. In the search view, click "search" and "replace" to enter text. The cursor will not blink here. In the terminal, enter a command. The cursor will not blink here. The setting should be consistently honored. (Note that this is an accessibility bug. It may not have a high hit rate because it isn't a commonly needed accessibility setting, but for people like me who depend on this setting, it is a very annoying bug. When the text input cursor blinks, it is extremely distracting to me and I have a very hard time focusing on what I am doing.) VS Code version: Code 1.59.1 (, 2021-08-19T11:56:46.957Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --
https://user-
it seems to be that the editor does not honour the operating system's cursor blink rate setting. This means that all workbench inputs that are using the editor do not honour this setting (ex: git commit message, search field in the extensions viewlet, etc.). The search viewlet is using the vanilla input element which honours the setting. Is this a known issue with the editor? Could you please investigate this? Thank you!
I don't believe there is any browser API that would allow us to read the system caret blink time. On Windows, there is a but it doesn't seem to be exposed to JS.

What do you think, would exposing the system caret blink time be a reasonable feature request for Electron?
do we use a custom cursor implementation for the editor ? Runtime uses the api to honor the interval for text inputs, so it is reasonable to expose it as an api if it helps custom implementations to sync with those intervals.
Yes
I turned on editor accessibility support and tried various editor.cursorBlinking setting values, but the cursor still blinks in the Settings editor search box.
Good find! In we adopt that the setting is forwarded in the repl and in the SCM input. Please feel free to use this issue to adopt forwarding this editor setting for the editor embedded in settings search!
should this be fixed. I still see the cursor blinking !
I will reopen the issue. Please close again if this works as expected.
right now the blinking is controlled by the setting rather than the OS. I fixed an issue where the Settings editor search inputbox wasn't picking up that setting properly, but I don't think the blinking ever corresponded to the OS. Verification steps: to a value such as or in the Settings UI. The value means no blinking should occur, so even though the blinking doesn't correspond to the system rate, at least it can be set to not blink. on the settings search box. The cursor blinking behaviour should correspond to the set value in step 1.
I think correct behaviour would be to use the OS settings by default. I generally expect my apps to honour global OS settings.