fix: guard webview find against disposed frame subtree (fixes #339314) - #339331

Summary

WebviewMainService.getFrameByName (electron-main) reads getWebContents(id).mainFrame.framesInSubtree.find(...) unconditionally. When a find / stop-find IPC request is handled against a webContents whose render frame has already been torn down (window closed, navigated away, or detached editor window disposed), mainFrame.framesInSubtree is undefined, so .find(...) throws TypeError: Cannot read properties of undefined (reading 'find') in the main process. This new-in-1.140.0 bucket affects 566 users / 736 hits across Mac, Windows, and Linux.

Fixes #339314
Recommended reviewer: @dmitrivMS

Culprit Commit

Code Flow

sequenceDiagram
    participant Renderer as Webview (renderer)
    participant IPC as ipcMain / ChannelServer
    participant Service as WebviewMainService
    participant Electron as Electron WebContents

    Renderer->>IPC: stopFindInFrame(id, frameName)
    IPC->>Service: call stopFindInFrame
    Service->>Service: getFrameByName(id, frameName)
    Note over Electron: ⚠️ Root cause:<br/>render frame already disposed,<br/>framesInSubtree is undefined
    Service->>Electron: getWebContents(id).mainFrame.framesInSubtree
    Note over Service: 💥 TypeError: Cannot read<br/>properties of undefined (reading 'find')

Affected Files

Repro Steps

The error is a timing-dependent race on the main process; it fires when a stop-find/find reply is handled after the target render frame is gone:

1. Open a webview-backed editor (e.g. Markdown preview, Simple Browser, or a detached editor window) and start Find (Cmd/Ctrl+F) inside it.
2. Close the webview / window (or navigate it away) while a find or stop-find request is in flight.
3. The in-flight stopFindInFrame / findInFrame IPC call reaches getFrameByName, whose webContents.mainFrame.framesInSubtree is now undefined, throwing the TypeError.
   • Detached editor windows (added in webview: Fix find in detached editor windows #337403) increase the likelihood because stop-find is now routed through auxiliary web-contents IDs that are disposed independently of the main window.

How the Fix Works

Chosen approach — webviewMainService.ts → getFrameByName(): the producer of the invalid state is Electron's render-frame disposal, which lives outside microsoft/vscode and cannot be reordered or awaited, so a consumer-side guard at this external boundary is the correct fix. getFrameByName now returns WebFrameMain | undefined: it checks contents.isDestroyed() and contents.mainFrame?.framesInSubtree before calling .find(...), returning undefined when the frame subtree is gone. The two callers (findInFrame, stopFindInFrame) already treat a missing frame as a no-op, so they early-return on undefined. This mirrors the existing disposed-frame guards already in this codebase: the contents.isDestroyed() check in setIgnoreMenuShortcuts (same file) and the frame.isDestroyed() guard in app.ts's isSafeFrame.

The genuine Unknown frame throw is deliberately preserved for the live-frame case (a real frame subtree that does not contain the named frame), so the error-telemetry pipeline still surfaces that distinct, actionable condition — only the disposed-webContents undefined read is suppressed.

Alternatives considered: adding ?./try/catch directly at the crash-site .find(...) was rejected because it would also swallow the meaningful Unknown frame signal and does not express why the value is absent; guarding explicitly on isDestroyed() / missing subtree keeps the disposed-frame no-op distinct from the live-frame "frame not found" error.

Recommended Owner

@dmitrivMS — author of the culprit commit #337403 and an active microsoft/vscode team member (238 commits in the last 90 days), who owns the webview find-in-frame routing changed by that PR.