Restore view states of revealed editors in other groups when Quick Open closes

[Copilot]

When using Quick Open to navigate to a symbol (e.g., file@symbol) in a file already visible in another split view, that view scrolls to show the symbol. On accept or cancel, the scroll position was lost.

Changes

• PickerEditorState (quickaccess.ts):

  • Track editors revealed in other groups via revealedEditorsInOtherGroups map
  • Save view state before revealIfOpened opens an editor in another group
  • Add restoreEditorViewStates() to restore just revealed editors' view states
  • Call restoreEditorViewStates() from restore() on cancel

• AnythingQuickAccessProvider (anythingQuickAccess.ts):

  • Call restoreEditorViewStates() on accept when opening to active group

• Test (quickAccess.test.ts):

  • Add test for restoreEditorViewStates with multiple editor groups

Behavior

Implements Solution C from the issue discussion: keep revealIfOpened behavior for symbol preview, but restore scroll positions in other groups when the picker closes (both ESC and ENTER).

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Consider option for Go To File.../Quick Open not to scroll to symbols in unfocused editors / splits</issue_title>
<issue_description>

When launching the Go To File... / Quick Open palette to navigate to a symbol in another file with multiple views open, if that file is open (even in a tab which is not currently active) in an unfocused split view, the other view will scroll to that symbol's position. For me, this is disruptive: I want to keep that view in it's current position for reference while I edit another position in my current view. (This is how it would work in Sublime Text, where the file / symbol launcher seems to be per-view rather than global.)

In case that paragraph was unclear or if I have used some terminology wrong, I'll give a concrete example (also asked on StackOverflow here):

Say I have multiple editors / split views open, say with file a.py on the left and b.py in the right, with my focus in the right view. Then I may want to navigate to a symbol in a.py while staying in the right view, and I try to do this by typing something like a@sym into the Quick Open input. But, as soon as I hit the @, the left view scrolls to an arbitrary symbol (the first suggested by the dialog), losing my place in the editor. If I type symbol , the left tab will scroll to that symbol. However, upon hitting Enter/Return, the same position will be opened up in the right view.

Is there a way to change VS Code's behavior to be like Sublime's here? If not, would it be possible to consider this as a feature request? Thanks!</issue_description>

<agent_instructions>make it nice</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@TylerLeonhardt Yeah I see this behavior

Screen.Recording.2025-11-14.at.4.13.08.PM.mov

similar but not as bad behavior is when you ctrl+enter which should open a file to the right side:

Screen.Recording.2025-11-14.at.4.32.47.PM.mov

It does, but it leaves behind the file in the previous group.

I do think that showing the editor is useful (it might even be needed to get the fully resolved symbols), but I think it should:

1. show up transient in the active group
2. if Ctrl+ENTER is hit, it should not leave behind an editor in the previous group

I'm pretty sure this is caused by this open openTransientEditor:

vscode/src/vs/workbench/contrib/search/browser/anythingQuickAccess.ts

Lines 936 to 939 in 817c9ac

	await this.pickState.editorViewState.openTransientEditor({
	resource: activeGlobalResource,
	options: { preserveFocus: true, revealIfOpened: true, ignoreError: true }
	});

and this openEditor with ACTIVE_GROUP as the target:

vscode/src/vs/workbench/contrib/search/browser/anythingQuickAccess.ts

Line 1128 in 817c9ac

await this.editorService.openEditor(resourceEditorInput, targetGroup);

@bpasero before I go playing with any of this, do you recall any technical reasons for doing the current behavior?</comment_new>
<comment_new>@bpasero
This is caused by using revealIfOpened which will always prefer an editor that is opened anywhere to reveal and show. I think you are asking for trouble if you were to change that because a lot of users likely rely on it that are annoyed if the current editor gets replaced.</comment_new>
<comment_new>@TylerLeonhardt
@bpasero What I see feels like a bug (which is shown in the videos):

1. Have 2 editor groups:
   1. (group 1)
      • bar.ts as the editor in forefront
      • foo.ts with a symbol called symbol
   2. (group 2)
      • baz.ts which has focus
2. Open Go To File and type foo@symbol, which causes group 1's instance of foo.ts to reveal
3. Hit ENTER to open that symbol
4. 🐛 foo.ts is opened in group 2 and foo.ts in group 1 is still left open so you have two of the same file open at the same time

My expectation would be either:

• the foo.ts in group 1 is focused and no other instances of foo.ts are opened on ENTER. That instance is used.
• foo.ts is opened in group 2, and the previous editor (bar.ts) is revealed in group 1

Additionally, what @cwindolf really wants maybe, there could be a setting to disable this revealIfOpened and instead prefer the active group.</comment_new>
<comment_new>@bpasero
@TylerLeonhardt yeah arguably the revealing of the editor in group 1 should be reset once the final editor is opened in group 2.

I see 2 possible fixes: either we reveal the editor always in the same group (which would match the final ...

• Fixes Consider option for Go To File.../Quick Open not to scroll to symbols in unfocused editors / splits #277185

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.