[feature-request]: Floating editor windows

[kittaakos]

Feature Description:

Something like what VS Code (1.85.0) can do: https://code.visualstudio.com/updates/v1_85#_floating-editor-windows

[tsmaeder]

As far as I can see, VS Code is also using the same approach of just moving the html to a different window, just like we did it for the secondary window support. I believe CSS support, etc. should just work since it's based on webpack finding the right CSS, which is the same mechanism as in the main window.
One difference is that they move the editor group handling with the editors, so you can have multiple editor tabs complete with their toolbars in the secondary window. This would be very welcome for other instances of secondary window support (like terminals) anyway, but looks more complicated and needs analysis.

[tsmaeder]

A little experimenting shows that the CSS does not get loaded properly when an editor is moved to a secondary window. The problem seems to be that we're missing a call to StandaloneThemeService.registerEditorContainer(domElement);. The StandaloneEditor calls this from the constructor, which adds the "monaco-colors" style element the the document header. VS code creates a new instance of the editor in the "AuxiliaryWindow", which registers the style element there.

A second problem I ran into is that beginning with _backgroundTokenizeWithDeadline(), the editor tries to post some messages via $globalThis, which leads to errors in the console. This seems to happen regularly while you edit in the secondary window.

Thirdly, opening other editors, for example with ctrl-click fails silently. I would guess we need to hook up the open event properly.

Other things like hover or content assist seem to work fine, though. Editing and saving seem to work fine, as well.

[tsmaeder]

Extending our current "external window" support to text editors would entail (IMO)

1. Coming up with a contribution point that allows contributors to hook into the process of moving the widget into a secondary window
2. Use this mechanism to set up the correct host communication for webviews (see acquireVsCodeApi(), etc. Currently, this support is hard-coded in secondary-window.html.
3. Make the monaco editor widget into an ExtractableWidget and use the hook contribution from above to load the proper css values
4. Make opening links work.

If all goes well, I think these steps should be doable inside two weeks. Steps 1 and 2 could be done as a first step, in order to allow for smaller PR's. Although what we have now works, I don't think it's architecturally correct with secondary window support knowing about webviews.

[tsmaeder]

Supporting layouts for extracted widgets (having multiple widgets in the same external window) would not change the current architecture as far as css, webview communications, etc. are concerned. However, we would have to

1. Extend our widget management to allow widgets to live in multiple external windows (ApplicationShell).
2. Set up the appropriate phosphor widgets when opening a secondary window. That includes toolbars. I assume the main menu would remain on the main window.
3. Set up d&d support for moving widgets to secondary windows

Once we start using drag and drop, should we support moving widgets between secondary windows and back to the original window?

[tsmaeder]

Reminder: my branch for this is 13163_investigation

[tsmaeder]

Should have a look at #13214 while we're at it. Editors are not much use if you can't reopen them.

[tsmaeder]

Related and still open feature request: #11648

[tsmaeder]

Context menus are broken even for our current extractable Windowy: #12722

Problem lies in our implementation of IContextMenuService, but also the Phosphor menu widget does not work with secondary windows: the menu is attached to the current global document variable, which is always the main menu.

[tsmaeder]

There is another problem related to the "references" zone view: the view uses a ListView which in turn is has a SmoothScrollableElement extending AbstractScrollableElement. When the list tries to send an open event, it checks whether the mouse event target element is inside the scrollable element, but this check always seems to fail.

[tsmaeder]

Turns out target instanceof target.ownerDocument.defaultView.HTMLElement === true, but target instanceof HTMLElement === false. Different windows seems to have different class instances for HTMLElement. Go figure!