Suggestion: Test coverage for Copilot chat in floating (auxiliary) windows

# Suggestion: Test coverage for Copilot chat in floating (auxiliary) windows

- **Drafted:** 2026-08-27
- **Type:** Suggestion for `microsoft/vscode` (test coverage / regression prevention)
- **Affected area:** Auxiliary (floating) window rendering of Copilot chat and related editor widgets

First, thank you for VS Code — it is a pleasure to use, and floating windows plus Copilot chat are a great combination. This is offered gently as a small suggestion, not a complaint.

Why this matters to us: each of these incidents tends to cost roughly half a day of troubleshooting or hunting for a workaround. VS Code is such a powerful and useful IDE that we simply cannot afford not to use it. Our corporate IT team maintains a baseline version as a safe home to fall back to, but that build usually lags well behind and misses helpful features from the latest release — so staying current matters to us. That is why a little extra test coverage around this area would go a long way toward stability.

Over about two weeks we happened to run into two core issues, both while using Copilot chat in a floating/auxiliary window, and both seemingly from the same underlying cause: DOM nodes created against the **main** window's `document` while the component is rendered inside a **child/auxiliary** window (`auxiliaryWindowService.ts` guards `document.createElement` on aux-window documents, so such a call throws instead of rendering).

Because it surfaced at more than one call site, it might be worth a little more automated coverage for the auxiliary-window path. A few ideas:

- Chat session editor in an auxiliary window — moving a chat session editor into an auxiliary window and checking the pane renders without throwing (the `createDormantHost` / "Move to New Window" case).
- Suggest widget in an auxiliary window — triggering `/` completions in a chat input hosted in an auxiliary window and checking the list renders (the #330736 case).
- DOM-creation guard test — rendering the chat input and its popups against an auxiliary-window `document` and checking no "Not allowed to create elements in child window" error occurs.

Recent related issues: #330736 (fixed in 1.134.0 via #330777), #332955, #332924, #332777, and earlier occurrences of the same class #326645, #327958, #320797 (fixed in 1.125.0).

> This is a draft suggestion for `microsoft/vscode`. It cannot be filed from an Enterprise Managed User (EMU) account; it could be submitted from a personal GitHub account or routed through internal/Microsoft support.
>
> **A note of appreciation:** VS Code is a remarkably capable and polished editor, and the floating-window and Copilot chat features are genuinely useful in daily work. Thank you to the Microsoft engineering team for their continued craftsmanship. The notes below are offered gently, only in the hope of being helpful.

---

The sections below are supporting detail for this repository's records.

## Summary

Over about two weeks we happened to run into two VS Code core issues, both while using Copilot chat in a floating/auxiliary window, and both seemingly from the same underlying cause: code that creates DOM nodes against the **main** window's `document` while the component is rendered inside a **child/auxiliary** window. `auxiliaryWindowService.ts` intentionally guards `document.createElement` on aux-window documents (so `x instanceof HTMLElement` keeps working), so such a call throws instead of rendering.

Because it surfaced at more than one call site, it may be that the auxiliary-window path could benefit from a little more automated coverage. This is just a suggestion, not a critique.

## Background: recent incidents

| Incident | Date | Symptom | Root cause / call site | Upstream tracking |
| --- | --- | --- | --- | --- |
| Suggest widget fails in floating chat window | 2026-08-13 | Typing `/` in the chat input renders no suggestion list | `SuggestWidget` measurement creates its element from the aux-window `document` | [#330736](https://github.com/microsoft/vscode/issues/330736) — fixed in 1.134.0 via PR [#330777](https://github.com/microsoft/vscode/pull/330777) |
| Moving a Copilot chat session to a new window fails | 2026-08-27 | Red "The editor could not be opened due to an unexpected error" screen; chat never renders | Chat/agent session editor (`createDormantHost`) creates DOM elements from the wrong window `document` | [#332955](https://github.com/microsoft/vscode/issues/332955), [#332924](https://github.com/microsoft/vscode/issues/332924), [#332777](https://github.com/microsoft/vscode/issues/332777) |

A couple of related, earlier occurrences of the same error class (different call sites) suggest it recurs from time to time:

- [#326645](https://github.com/microsoft/vscode/issues/326645) — terminal `@xterm/addon-webgl` in an auxiliary window.
- [#327958](https://github.com/microsoft/vscode/issues/327958) — terminal in an auxiliary window.
- [#320797](https://github.com/microsoft/vscode/issues/320797) — `chatImageUtils` (fixed in 1.125.0).

## The common error

```text
Not allowed to create elements in child window JavaScript context.
Always use the main window so that "xyz instanceof HTMLElement" continues to work.
at document.createElement (workbench.desktop.main.js)
```

## A gentle suggestion

If it seems worthwhile, some automated coverage for Copilot chat rendered in an auxiliary (floating) window might help catch this pattern early. A few ideas:

1. **Chat session editor in an auxiliary window** — moving a chat session editor into an auxiliary window and checking the pane renders without throwing (the `createDormantHost` / "Move to New Window" case).
2. **Suggest widget in an auxiliary window** — triggering `/` completions in a chat input hosted in an auxiliary window and checking the list renders (the #330736 case).
3. **DOM-creation guard test** — rendering the chat input and its popups against an auxiliary-window `document` and checking no "Not allowed to create elements in child window" error occurs.

## Notes

- Analyzed with the assistance of VS Code Copilot. Encountered in a corporate work environment; would be reported from a personal GitHub account.

Start with auxiliaryWindowService.ts and trace the createDormantHost / “Move to New Window” path, then inspect the SuggestWidget path for chat input in an auxiliary window. No test file is named; done means adding coverage for the session editor, slash-completion widget, and DOM-creation guard without the reported child-window error.

Written by the indexing model from the issue text.