Skip to content

modal - improve handling of Escape key and expand use of modal editors to more kinds#299060

Open
bpasero wants to merge 3 commits intomainfrom
ben/massive-mollusk
Open

modal - improve handling of Escape key and expand use of modal editors to more kinds#299060
bpasero wants to merge 3 commits intomainfrom
ben/massive-mollusk

Conversation

@bpasero
Copy link
Member

@bpasero bpasero commented Mar 3, 2026

fix #297334

Copilot AI review requested due to automatic review settings March 3, 2026 20:57
@bpasero bpasero self-assigned this Mar 3, 2026
@vs-code-engineering vs-code-engineering bot added this to the 1.111.0 milestone Mar 3, 2026
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Expands modal editor usage to additional preferences-related editors and refines Escape handling for modal editor close behavior via keybindings (instead of ad-hoc DOM handling).

Changes:

  • Preferences/keybindings/settings JSON editors now choose the modal editor group whenever workbench.editor.useModal is enabled.
  • Modal editor Escape-to-close handling is moved from a dedicated DOM Escape listener to command/keybinding rules with focus-sensitive precedence.
  • Close Modal Editor keybinding is split into two Escape rules to adjust priority depending on whether a text editor is focused.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
src/vs/workbench/services/preferences/browser/preferencesService.ts Routes more preferences editors (including JSON/textual variants) into the modal editor group when modal mode is enabled.
src/vs/workbench/browser/parts/editor/modalEditorPart.ts Removes custom Escape close logic; relies on command/keybinding handling and keeps command filtering logic.
src/vs/workbench/browser/parts/editor/editorCommands.ts Updates the modal close command to use two Escape keybindings with different weights based on editor focus.
Comments suppressed due to low confidence (1)

src/vs/workbench/services/preferences/browser/preferencesService.ts:383

  • getEditorGroupFromOptions now returns MODAL_GROUP whenever workbench.editor.useModal is not off, which means explicit targeting options like openToSide / groupId are ignored even for JSON settings/keybindings editors. Previously the JSON settings path (and the textual keybindings path) could still honor openToSide/groupId under useModal: 'some'. Consider prioritizing explicit openToSide/groupId over modal (or introducing an explicit flag to force modal) to avoid breaking callers that pass these options intentionally.
	private getEditorGroupFromOptions(options: { groupId?: number; openToSide?: boolean }): PreferredGroup {
		if (this.configurationService.getValue<string>('workbench.editor.useModal') !== 'off') {
			return MODAL_GROUP;
		}
		if (options.openToSide) {
			return SIDE_GROUP;
		}
		if (options?.groupId !== undefined) {
			return this.editorGroupService.getGroup(options.groupId) ?? this.editorGroupService.activeGroup;
		}

aeschli
aeschli previously approved these changes Mar 3, 2026
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Modal settings editor: Edit in settings.json is disrupting

4 participants