Skip to content

js: add window.postMessage - #340

Merged
tannevaled merged 1 commit into
mainfrom
js-window-postmessage
Nov 2, 2026
Merged

tannevaled merged 1 commit into
mainfrom
js-window-postmessage

Conversation

@tannevaled

Copy link
Copy Markdown
Contributor

Summary

Continuing the JSLog-sweep method (rounds 199-200) in parallel with a
dedicated investigation of round 200's own flagged <canvas>.getContext()
lead (stripe.com) — correctly declined again: grep -rn "getContext|CanvasRenderingContext|canvas" js/ found zero rasterization
machinery anywhere to build a narrow stub on (unlike clip-path, round 194,
which reused existing mask/group-buffer paint infrastructure). Rendering
stripe.com through this engine's own pipeline also produced zero JSLog
lines at all (none of its 85 <script> tags executed) — a separate puzzle
flagged for a future round, blocking confirmation of the actual canvas call
pattern.

Confirmed real trigger for this round's fix: Google's own
gstatic.com/recaptcha/.../recaptcha__en.js — one of the most
widely-deployed third-party scripts on the real web — calls bare
postMessage(...) unconditionally at load. Reproduced live on spotify.com:
ReferenceError: postMessage is not defined, the same whole-script-abort
shape round 50's missing customElements had.

  • grep -rn postMessage js/ found postMessage existing ONLY as a method
    on MessagePort objects (MessageChannel, net.go's wirePort — which
    already delivers for real via the bounded event-loop job queue) — there
    was no bare global window.postMessage at all.
  • Fix, matching rounds 199/200's own size class: a single no-op entry
    in js/window.go's existing installStubs bucket (the established home
    for best-effort/state-only window-level functions — scrollTo, alert,
    open, window.location.assign()'s own precedent). HTML Standard
    §9.4.3's postMessage queues a task firing a message event on a target
    window; this engine's single-document model has no real second
    window/frame to deliver to (window/self/top/parent already alias
    the one global object), so this stops the crash without simulating
    delivery no confirmed trigger needs.
  • FIDELITY.md/README.md updated (new round-201 log entry, Known Gaps
    entries — one CLOSED, the canvas lead's re-investigation documented with
    the new stripe.com puzzle — and "Works today" bullets).

Test plan

  • go test ./... — all green, no coverage-gate regression
  • js/js_test.go's new TestWindowPostMessageDoesNotThrow (the real
    trigger's own call shape, both 2-arg and object-options forms) and
    TestWindowStubs extended alongside the other no-op globals
  • Independently re-rendered the real live trigger (spotify.com) through
    this engine's own pipeline before/after: the ReferenceError
    disappears from JSLog
  • go build ./... && go vet ./... clean

🤖 Generated with Claude Code

…again

Continuing the JSLog-sweep method (rounds 199-200) in parallel with a
dedicated investigation of round 200's own flagged
<canvas>.getContext() lead (stripe.com) - correctly declined again:
grep -rn "getContext|CanvasRenderingContext|canvas" js/ found zero
rasterization machinery anywhere to build a narrow stub on (unlike
clip-path, round 194, which reused existing mask/group-buffer paint
infrastructure). Rendering stripe.com through this engine's own
pipeline also produced zero JSLog lines at all (none of its 85
<script> tags executed) - a separate puzzle flagged for a future
round, blocking confirmation of the actual canvas call pattern.

Confirmed real trigger for this round's fix: Google's own
gstatic.com/recaptcha/.../recaptcha__en.js - one of the most widely-
deployed third-party scripts on the real web - calls bare
postMessage(...) unconditionally at load. Reproduced live on
spotify.com: ReferenceError: postMessage is not defined, the same
whole-script-abort shape round 50's missing customElements had.

grep -rn postMessage js/ found postMessage existing only as a method
on MessagePort objects (MessageChannel, net.go's wirePort, which
already delivers for real via the bounded event-loop job queue) -
there was no bare global window.postMessage at all.

Fix, matching rounds 199/200's own size class: a single no-op entry
in js/window.go's existing installStubs bucket (the established home
for best-effort/state-only window-level functions - scrollTo, alert,
open, window.location.assign()'s own precedent). HTML Standard
Section 9.4.3's postMessage queues a task firing a message event on a
target window; this engine's single-document model has no real
second window/frame to deliver to (window/self/top/parent already
alias the one global object), so this stops the crash without
simulating delivery no confirmed trigger needs.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@tannevaled
tannevaled merged commit 71b7f81 into main Nov 2, 2026
13 checks passed
@tannevaled
tannevaled deleted the js-window-postmessage branch November 2, 2026 21:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant