This builds on top of 995efd57e6. That commit
tracked the number of requests being made on a single XHR instance (because a
new request can be initiated from a load/error callback of an existing one).
However, that was unbound. It wasn't just 1 old + 1 new, it was an unlimited
number of new requests, because we didn't prevent sending while sending was
already active.
This adds a boolean to track our send state, and prevents a send from happening
when a send is already active.
MessageEvent.getSource returned the bare *Window, the only window accessor
that did not go through Window.Access.init. Every other accessor
(iframe.contentWindow, window.parent, window.top) wraps a cross-origin target
as *CrossOriginWindow. JS object identity is keyed by Zig pointer
(identity_map), so cross-origin event.source (the *Window) and
iframe.contentWindow (&window._cross_origin_wrapper) resolved to different JS
objects: `event.source === iframe.contentWindow` was false cross-origin while
true same-origin.
The WHATWG HTML spec requires these to be the same object regardless of origin
(one WindowProxy per browsing context; MessageEvent.source is that
WindowProxy). The mismatch breaks postMessage handshakes that authenticate the
sender by reference identity, e.g. keycloak-js's 3rd-party-cookie check
(`if (iframe.contentWindow !== event.source) return;`), which then times out
and fails OIDC init.
Route getSource through Window.Access.init(frame.window, source) — exactly like
IFrame.getContentWindow — so both paths resolve to the same per-frame proxy.
Same-origin behaviour is unchanged. Verified against Chrome 149 (identity holds
cross- and same-origin). Adds a regression test, cross_origin_message_source.html.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
frameChildFrameCreated emitted Page.frameAttached with its payload wrapped
in an extra `.{ .params = ... }`. CDP.sendEvent already places the payload
into the event's `params` field, so this produced a malformed wire event
with double-nested params (`params.params.frameId`) — unlike every sibling
frame event in the same function, which passes its fields flat.
CDP clients (e.g. Playwright via connectOverCDP + page.route) parse
frameId/parentFrameId at the top level of params. With the fields one level
too deep the client never registers the child frame, so when that frame's
Fetch.requestPaused arrives it is bare-continued instead of matched against
a route. The result: request interception (page.route / Fetch) silently does
not apply to iframe (sub-frame) document navigations — the iframe loads from
the real network. The interception layer itself was never at fault; it does
emit requestPaused for sub-frames.
Drop the extra wrapper so the payload is flat. Add a regression test that
dispatches frame_child_frame_created and asserts Page.frameAttached carries
frameId/parentFrameId directly under params (fails on the double-nested shape).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The parsing behavior of HTML depends on what we're parsing it for. innerHTML on
a script is parsed (slightly) differently than for, say, the body. html5ever
supports this, we just have to give it the tag name (which we have access to
in the html5ever bridge already).
Also, extend the tag types that dump does NOT escape for beyond noscript/script.
Fixes warnings with some NextJS sites
This causes some feature detection (jquery/amazon) to think we're some old
version of IE, which then requires IE-specific APIs. It sets a ".55" value and
then reads it, expecting 0.55.
This is a noop implementation of navigator.sendBeacon. It often shows up in the
logs. I believe that returning "true" to signal successful queuing is correct
as it'll prevent any attempts to fallback. However, I'm less sure that noop'ing
the entire thing is better than just implementing it.
This reverts recent(ish) changes to telemetry which moved it from its own thread
onto the main thread.
The downside is: we have an extra thread.
The upside is largely that Network.zig becomes drastically simpler and more
efficient. There's a bunch of machinery in Network.zig to support arbitrary
workers, of which Telemetry is the only one. There's also a lot of code to
support an optional multi and requests made to is. This is all removed.
Also, fetch, agent and mcp without a cdp server no longer even need to start
the network loop. And, it IS started (e.g. serve/cdp), there's no longer an
arbitrary 250ms wakeup on poll to progress workers. Nor can telemtry block CDP.
Telemetry's implementation itself was changed. The ring buffer was removed in
favor of a double-buffer arraylist. When telemetry is disabled, this saves
64Kb of memory. When it's enabled, it creates more allocator churn, but should
still use less memory in most cases (and never more). Finally, Telemetry is
given its own easy connection rather than using one out of the pool (which
workers would maybe like to use).
When you create a worker (new Worker(...)), it creates 2 objects: the Worker
that lives in the caller, and the WorkerGlobalScope (WGS) which is more or less
like a Window, with its own v8::Context.
But WGS is really a base class meant to be used with various types of workers.
new Worker() shouldn't create a WGS directly, it should create a
DedicatedWorkerGloblaScope, which inherits from WGS. For now, our WGS can only
have 1 type (DedicatedWGS).
This fixes various errors on www.kitandace.com which would launch workers, and
then do a check (if (this === DedicatedWorkerGloblaScope)). It _should_ have
returned true, but it didn't (because our workers were WGS).
Implements `url_resolve_with_encoding` and `url_resolve_without_encoding` in Rust; that way, we don't pay the cost of extra `Box`es we allocate during resolving.
This is the only main change in this branch compared to main that could explain
the Debug check failed: isolate()->CurrentLocalHeap()->IsRunning() failure
being reported.
This fixes two bugs introduced in the previous PR. First, in non-CDP mode, when
there's nothing to do except v8 background tasks, we wait for those background
tasks.
Second, the various wait helpers (e.g. waitForFrame) now return the first error
of any WaitCondition.
In trying to fuzz test a different issue, I ran into a reproducible case where
we end up with a broken handlescope stack. The issue requires a large number
of handlescopes created with aggressive GC, so hopefully it isn't something
that too many users have run into.
The issue is that a single HandleScope address is used to initialize two
HandleScopes. The fix could just be to create a 2nd HS variable (to get a 2nd
address), but the first initialization is unnecessary and can just be removed.
(Note that EventManager dispatch creates its own HandleScope, so the one
removed in frameCompletedLoading really did nothing)
