Just improves the log a little to try and capture the name of what was
constructed. We see this often in WPT tests, which is probably WPT testing the
illegal constructor behavior, but it's hard to be sure. Having the name logged
gives us enough detail to see if the behavior is correct or not.
Also, downgraded the log level from warn -> info.
This is a follow up to https://github.com/lightpanda-io/browser/pull/2365 which
implements a different fix with different performance tradeoffs.
To recap, #2365 fixed an issue where the frame used to track the dom version
was the frame here the JS was being executed, not necessarily where the node
existed. This would cause the caching to break. #2365 fixed this by always
using the node's frame. But this is relatively expensive, requiring that we
find the owning document of a node in order to get its frame. This traversal
has to happen on every dom manipulation (to update the version) and every cached
read (to verify the dom version hasn't changed). We _could_ store the owning
frame on every Node, but that's relatively memory expensive to do.
This commit moves the dom version from the Frame to the Page. This allows us
to use the executing Frame to get the page (`frame._page`) which is much faster
than traversing the parent nodes to find the document. The downside is that a
mutation in Frame1 will invalidate the cache in Frame2. Given that many sites
have a single frame, this seems like a clear win.
buildJSONVersionResponse read the port from app.config.port(), which
is the configured value (still 0 with --port 0). Pass the OS-assigned
port from the bound address instead, so webSocketDebuggerUrl matches
the actual listener.
The integration test previously asserted a literal ws://127.0.0.1:9222/
that happened to match the test config's default port but not the
harness's hardcoded bind address (9583) — drop the URL assertion; the
buildJSONVersionResponse unit test already covers URL formatting.
XHR, for example, needs the context to properly shutdown. It get the page via
exec.context.page. Now, we could store the page on the XHR instance, sure. But
the point is the js.Context should never need the HttpClient, so it should
always be safe to abort inflight requests before canceling the context.
Fixes some flaky WPT crashes.
This re-implements the CDP navigate action fast-path when a page is in a
waiting state. It was removed for https://github.com/lightpanda-io/browser/pull/2297.
I believe this fast-path is still safe to do given that a page in _waiting has
had no navigation event yet and thus has nothing to preserve. The upside is
being able to re-use the existing [bare] v8::Context.
Per DOM §2.9 step 4 substep 8 ("Inner invoke"), an exception thrown by a
listener callback must be reported to the realm's global, not propagated
out of `dispatchEvent`. Subsequent listeners on the same target and the
rest of the capture/bubble walk must still run.
Both `EventManager.dispatchPhase` (DOM targets) and
`EventManagerBase.dispatchDirect` (Window/XHR/AbortSignal/etc.) wrapped
the V8 callback invocation in raw `try`, so a listener throw aborted the
whole dispatch and surfaced as an uncaught exception at the
`Runtime.evaluate` boundary. The inline-handler invocation a few lines
above already used `catch |err| log.warn(...)`; this just extends the
same shape to the listener switch.
Closes#2367
This fixes 2 separate issues, driven by the [very] broken
/dom/ranges/Range-insertNode.html WPT test.
The first, and simplest, is that when a script element is cloned, its executing
_executed and _force_async flags need to be copied. This prevents double-
execution.
The second is more complicated: dom version tracking (as a caching mechanism
used in various live collection) has to be against the node's owning frame, not
the frame that's executing the JavaScript. This includes both the version
checking and version change (on dom mutation). This introduces a relatively
expensive node -> document -> frame on every mutation and cache read. This is
potentially worth optimizing somehow, in a follow up PR. Two options come to
mind:
1 - Track a single dom version on the Page. Mutation in frame1 invalidates
frame2.
2 - Optimize for the frame-less case. If a page has no frame, then the calling
context should be equal to the owning document's frame.
When Fetch.httpErrorCallback rejects the promise, microtasks are run. Those
microtasks could do anything, including triggering a frame shutdown (e.g. via
a navigation event). The result is that we end up with
httpErrorCallback
httpShutdownCallback
And the code simply isn't designed to handle that. httpErrorCallback now takes
control of the cleanup, capturing the `self._owns_response` in a local, and
disabling so that any nested `httpShutdownCallback` are noops.
Wire the existing multipart encoder (FormData.multipartEncode) into the
fetch and XHR body paths. Previously both entry points typed their body
parameter as ?[]const u8, so the JS->Zig bridge silently coerced any
FormData JSValue via toString() and emitted "[object FormData]" with
Content-Type: application/x-www-form-urlencoded.
Introduces a BodyInit tagged union covering FormData, URLSearchParams,
Blob, and bytes. A small extract() helper returns the serialized bytes
plus the spec-mandated default Content-Type (Fetch §6.5 step 8 / XHR
§4.7.6 step 4). Both Request.init and XMLHttpRequest.send apply the
default Content-Type only when the caller hasn't already set one.
Closes#2357
Add worker.setInterval, clearInterval, setTimeout, clearTimeout by extracting
the scheduling logic from Window and making it use Execution rather than Frame.
