Fix "Object has been destroyed" error when BrowserView is disposed after window close

[Copilot]

When an Electron BrowserWindow fires 'closed', the window object is already destroyed before any listeners run. BrowserView listens to onDidClose and calls dispose(), which called contentView.removeChildView() on the now-destroyed BrowserWindow — throwing "Object has been destroyed".

Changes

• browserView.ts — dispose(): Guard removeChildView with !win.isDestroyed(), consistent with the existing isDestroyed() check already present for webContents.close() a few lines below.

// Before
this._currentWindow?.win?.contentView.removeChildView(this._view);

// After
const currentWin = this._currentWindow?.win;
if (currentWin && !currentWin.isDestroyed()) {
    currentWin.contentView.removeChildView(this._view);
}

The optional chaining ?.win only guards null/undefined — it does not protect against a valid-but-destroyed BrowserWindow reference, which is the state after 'closed' fires.

[vs-code-engineering]

📬 CODENOTIFY

The following users are being notified based on files changed in this PR:

@jruales

Matched files:

• src/vs/platform/browserView/electron-main/browserView.ts

[Copilot]

Pull request overview

Fixes an Electron main-process crash/exception caused by disposing a BrowserView after its hosting BrowserWindow has already been destroyed (a known state by the time the 'closed' event listeners run). The change makes BrowserView.dispose() resilient to destroyed-window references.

Changes:

• Add an isDestroyed() guard before calling BrowserWindow.contentView.removeChildView(...) during BrowserView.dispose().
• Keep existing webContents.isDestroyed() guard behavior intact for webContents.close(...).

Show a summary per file

File	Description
src/vs/platform/browserView/electron-main/browserView.ts	Prevents "Object has been destroyed" by skipping removeChildView when the hosting window is already destroyed during disposal.

Copilot's findings

• Files reviewed: 1/1 changed files
• Comments generated: 0