Change:
import { NOTEBOOK_EDITOR_ID, NotebookWorkingCopyTypeIdentifier } from 'vs/workbench/contrib/notebook/common/notebookCommon'; import { NotebookEditorInput } from 'vs/workbench/contrib/notebook/common/notebookEditorInput'; import { NotebookPerfMarks } from 'vs/workbench/contrib/notebook/common/notebookPerformance'; <del> import { GroupsOrder, IEditorGroup, IEditorGroupsService } from 'vs/workbench/services/editor/common/editorGroupsService'; </del> <ins> import { GroupsOrder, IAuxiliaryEditorPart, IEditorGroup, IEditorGroupsService, IEditorPart } from 'vs/workbench/services/editor/common/editorGroupsService'; </ins> import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; import { IEditorProgressService } from 'vs/platform/progress/common/progress'; import { InstallRecommendedExtensionAction } from 'vs/workbench/contrib/extensions/browser/extensionsActions';

Discussion:
Steps to Reproduce: a notebook into a aux window window screen cheese restoring the notebook <img width="1612" alt="image" src=""
thanks for the report. I found that I'm struggling with the inconsistency of or : If I use all the time it works for opening notebook in main window it works when opening in floating window when closing the floating window, the notebook editor will never get restored properly as is still being set to the floating window, but it should be the main window when we try to create the notebook again. Thus I started to check what's the owner code window for the notebook editor container DOM node by , it fixes all above scenarios. However this approach breaks when reloading VS Code. Digging into this I found that after window reload and we attempt to restore the notebook editor, always returns the main code window instead of the floating one. 's turns out to be the main window's document. I guess it's because is created under an div that's created under the main document. With the inconsistency, I couldn't figure out where to attach the notebook DOM nodes always correctly. is this an oversight?
Interesting, we do begin to restore floating windows from here: Specifically creating a floating window per state: The editor state is passed into the editor part of the floating window here: And then we create the grid widget with that state: However we only seem to be setting the grid widget to its parent container after restoring state: So as long as that did not happen, the owner document of the grid widget will be the main window! This is an issue because we decided to run always from the main window document and not the floating window document, otherwise the changes in our code would be a magnitude more involved. tl;dr until a is appended to its parent in the floating window, its owner document is the main window we always need to ensure to first append and then judge about the owner document this is hard to enforce and tbh I am expecting a lot more issues like these that we need to iron out going forward
thanks for sharing the details. I found we kind of have the right info to find the right code window for an editor input/pane, it's not yet exposed, so maybe we could introduce an API which everyone can use.

Here is my workaround to get this issue resolved, it's not great but I still merge this to ensure users not run into this, , what I was trying to do: The editor input can access its group, I should ideally use to get its part. However it seems during window reload, the aux window has zero groups. For example, if the main window has group 1 and 2, aux window has group 3, during window reload, main window does restore group 1 and 2, but it seems aux window has zero groups. So calling can't find a matching part, and it falls back to main window. I work around this via Once I get the right part, I attempt to read so I can use that to revive the . It's now working fine for all scenarios, but it would be awesome that there is one unified accurate API to get what's the right to use for an editor input.
I will see to allow to access to make this easier. However I think the real fix would be that the grid widget first appends created DOM nodes to the parent before going down the path of handing it off to components such as the editor. I will ping Joao on this and maybe we leave that part up for debt week as it may have some consequences.