Webview drops every postMessage from the extension host — origin check never matches

[FROWNINGdev]

Summary

src/webview/graph.tsx:192 guards the message listener with:

if (event.source !== window) return;

The comment above it asserts that in a VS Code webview the source field is the webview's own window. Measured, it is not. Every message the extension host posts is dropped before the payload is read, so the ER diagram panel never updates after it is first opened.

Measurements

Instrumented the listener to log before the guard, then toggled a model's checkbox in the sidebar (which pushes a fresh index):

MSG sameWindow=false  sameParent=false  sourceNull=false  type="index"

So the message genuinely arrives, carries the right type, and source is a real object that matches neither window nor window.parent. The guard rejects it.

Worth stressing that this was measured, not reasoned about. An earlier attempt to fix it by widening the check to event.source !== window && event.source !== window.parent was a guess, and the numbers above show it would not have worked either.

Why the panel still renders at all

Initial state does not come over the message channel. renderInto embeds it directly in the HTML at src/graphWebview.ts:147:

window.__INITIAL_INDEX__ = ${serialised};

GraphApp seeds useState from that (graph.tsx:178). So the first paint is always correct and the bug is invisible until something tries to update an open panel.

What is broken as a result

Two paths, both postMessage and both dead:

1. graphWebview.ts:235 — the index push when showGraph is called on an already-open panel.
2. graphWebview.ts:258 — the reply to the webview's ready handshake.
3. The theme message handled at graph.tsx:197, so a theme switch does not reach an open panel.

The sidebar visibility toggles hit this first. They are currently worked around at extension.ts:148 by re-assigning the panel HTML on every checkbox change — correct, but it re-renders the whole diagram and visibly flashes. That workaround is the only reason the feature works at all today.

Where the check came from

It was added to satisfy CodeQL's js/missing-origin-check. Any fix has to keep that alert quiet, so simply deleting the line is not a solution.

Directions worth investigating

Not yet verified — listing so the next person does not start from zero:

• Find out what event.source actually is. Log event.source === window.top, its location, and event.origin. The panel runs inside nested frames (active-frame inside the VS Code shell), so the host frame may be neither the immediate parent nor window.
• Check whether event.origin is stable enough to check instead of source. VS Code has changed webview origins between versions, so this needs testing across a range, not just the current build.
• Consider validating the payload shape rather than the sender. The CSP at graphWebview.ts:134 is already default-src 'none' with a script nonce, which is the real barrier to a hostile frame executing anything here; a discriminated-union check on data.type may satisfy CodeQL on its own.

Acceptance

• An open panel updates via postMessage — no HTML reassignment.
• The extension.ts:148 workaround is removed and toggling a checkbox no longer re-renders the whole diagram.
• CodeQL reports no js/missing-origin-check on graph.tsx.
• Verified by actually toggling a checkbox in a running Extension Development Host, not by reading the code.

[FROWNINGdev]

Found authoritative guidance and pushed a candidate fix in f93e5fd. Not yet verified against a running host — leaving this open until it is.

Matt Bierner (VS Code maintainer), on whether extensions must validate messages from the extension host — microsoft/vscode-discussions#1061:

I believe you should check that e.origin === window.origin instead of hardcoding any strings

That is a direct answer to the question this issue asks, and it explains why the original check could never work: the guard was written against source, and the sender's window identity is simply not the thing to compare. origin is. Hardcoding vscode-webview: also fails, because the scheme differs between the desktop app and vscode.dev — hence comparing against the webview's own window.origin rather than a literal.

src/webview/graph.tsx now reads:

if (event.origin !== window.origin) return;

tsc is clean and the suite is 104/104, but neither of those exercises the message channel — the only thing that proves this is toggling a checkbox in an Extension Development Host and watching an open panel update without a reload.

The extension.ts:148 full-re-render workaround stays until then. Deliberately: if the origin comparison is also wrong, messages stay dropped and the workaround still delivers the state, so the failure mode is "unchanged", not "regressed". Removing the workaround first would have turned a wrong guess into a broken feature.

Remaining to close:

• Confirm in a live host that an open panel updates via postMessage.
• Remove the extension.ts:148 workaround and confirm the diagram no longer flashes on toggle.
• Confirm CodeQL still reports no js/missing-origin-check.