Repository navigation
js: add window.postMessage - #340
Merged
Merged
Conversation
…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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 rasterizationmachinery 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 puzzleflagged 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 mostwidely-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-abortshape round 50's missing
customElementshad.grep -rn postMessage js/foundpostMessageexisting ONLY as a methodon
MessagePortobjects (MessageChannel,net.go'swirePort— whichalready delivers for real via the bounded event-loop job queue) — there
was no bare global
window.postMessageat all.in
js/window.go's existinginstallStubsbucket (the established homefor best-effort/state-only window-level functions —
scrollTo,alert,open,window.location.assign()'s own precedent). HTML Standard§9.4.3's
postMessagequeues a task firing amessageevent on a targetwindow; this engine's single-document model has no real second
window/frame to deliver to (
window/self/top/parentalready aliasthe one global object), so this stops the crash without simulating
delivery no confirmed trigger needs.
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 regressionjs/js_test.go's newTestWindowPostMessageDoesNotThrow(the realtrigger's own call shape, both 2-arg and object-options forms) and
TestWindowStubsextended alongside the other no-op globalsthis engine's own pipeline before/after: the
ReferenceErrordisappears from
JSLoggo build ./... && go vet ./...clean🤖 Generated with Claude Code