Change:
this._element.classList.add(ClassName.Widget); this._editorContainer = document.createElement('div'); const codeEditorWidgetOptions: ICodeEditorWidgetOptions = { <del> contributions: EditorExtensionsRegistry.getSomeEditorContributions([LinkDetector.ID, SelectionClipboardContributionID, 'editor.contrib.selectionAnchorController']) </del> <ins> contributions: [...EditorExtensionsRegistry.getEditorContributions(), ...EditorExtensionsRegistry.getSomeEditorContributions([LinkDetector.ID, SelectionClipboardContributionID, 'editor.contrib.selectionAnchorController'])] </ins> }; const font = _xterm.getFont(); const editorOptions: IEditorConstructionOptions = {

Discussion:
Type: <bFeature Request</b Sometimes, when using the terminal, I accidentally end up typing a command in the Focus Accessible Buffer. Many times I only realize the mistake when pressing the enter key to execute the command. In my opinion, it would be very useful if VSCode issued an alert informing that the focus is on an element that cannot receive data input. VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-12T11:46:48.659Z) OS version: Linux x64 6.3.12-200.fc38.x86_64 Modes: <!-- generated by issue reporter --
I see that the accessibility help is readonly. So we could tackle this as a broader request to notify users when they are typing in a readonly editor. This could be an audio cue - windows has some sounds like this where you are typing into a field that does not support it.
Thanks for the idea this makes a lot of sense to me. Would you rather an alert or audio cue? My thought would be an audio cue as suggests. The downside is I think we'd need a new audio cue, which seems to take awhile to get from our sound designer. Also cc and for their thoughts
In my opinion the audio cue would be better, but an alert will also do. There is already an alert message when I open a file, use the File: Toggle Active Editor Read-only command and try to edit something.
What about moving focus to the input field instead? Unless I type a key accidentally, this could even be helpful for productivity. One of the reasons why I still prefer to use the external terminal is because I don't have to wander where my focus is if I want to issue a command.
In my opinion moving focus to the input field is also a good idea. One of the advantages for me in using the accessible buffer is how easy it is to navigate the output of commands executed in the terminal. I can even copy the result of the command to paste it in a file or send it to someone else.
I agree, and that's why I'd like to use it more. Moving focus automatically if I try to type could be another step in that direction. I'm slightly concerned about accidental typing though.

Even in that case, it is still posible to press shift +Tab and the cursor would still be in the same place in the buffer. I would be curious to know your thoughts about this.
I concur! Playing audio cues for read-only editors might be a great solution by default. -- Instead of creating a new audio cue, what about using the existing one, such as "Terminal Bell (Disabled)"? -- the auto-focus to terminal input sounds really good to me as well. However, I would recommend adding the feature as a user-customizable optional setting because it might cause some confusion for novice users or accidental typing.
If we play an audio cue, the accessible buffer should stop accepting characters. It does now if one tries to type in it. I have also observed that if one moves between the accessible buffer and the input field, the cursor position in the accessible buffer gets reset even if no new command is issued. That is a problem if I'm trying to type a new command and need to review output from the previous one because each time I move focus to the accessible buffer, I have to find my place again. I'm happy to open a separate issue about that.
The buffer doesn't actually accept characters - the screen reader just reads the characters. I think maybe using would fix this? I'll investigate. Also, we need it to accept some characters - arrow keys for instance.
If I type characters, they are not only announced when I type them, they are present if I read the current line, and present in my Braille display. Of course, if I press any arrow key and the cursor moves, they get deleted immediately. Actually, if instead of pressing arrow keys alone I press CTRL +Left or Right arrow keys, I can move word by word and the characters I entered remain as part of the content. It doesn't seem to cause any harm in general, although I can imagine very special situations in which that behavior can be confusing. For example, if I'm reviewing a complicated argument as part of the help information for a command, if I accidentally press a key before reading the text in braille, I will find that ghost character written and may confuse it as being part of the argument.
Interesting and thanks for that insight. Does this happen in all read only editors currently?
Ok interesting - it doesn't happen in the other read only editors.

I debugged and realized this is because one of the contributions we provide seems to cause the readonly contribution to break.
if I provide any contributions at all, it doesn't work
we should also have this readonly behavior for the
The same behavior can be observed in the accessibility help menu.
yeah that's using the
Good to know. I thought the accessible view was something else. :) Thank you for clarifying.