https://github.com/lightpanda-io/browser/pull/1775 made blobs finalizable and
https://github.com/lightpanda-io/browser/pull/1795 made it possible to navigate
from blobs (important for WPT tests). This fixes a number of issues related to
both.
First, weak/strong ref'ing a value now uses the resolved value. When registering
a finalizer, we use the resolved value (the most specific type in the prototype
chain). For this reason, when toggling a weak/strong ref, we have to use the
same resolved value. This solves a segfault where a File is created, but
extended as a Blob (e.g. in createObjectURL).
Next, two issues were fixed when navigating to an invalid blob. First, the frame
is properly removed from the parent list on frame navigation error. Second,
on frame navigation error, we don't stop _all_ other navigations, we just log
the error and move on to the next frame.
processMessage no longer returns Zig errors when dispatchCommand fails —
it sends a CDP error response and continues. Update all expectError calls
to use processMessage + expectSentError instead.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Origins were introduced to group memory/data that can be owned by multiple
frames (on the same origin). There's a general idea that the initial "opaque"
origin is very transient and should get replaced before any actual JavaScript
is executed (because the real origin is setup as soon as we get the header from
the response, long before we execute any script).
But...with CDP, this guarantee doesn't hold There's nothing stop a CDP script
from executing javascript at any point, including while the main page is still
being loaded. This can result on allocations made on the opaque origin which
is promptly discarded.
To solve this, this commit introduced origin takeover. Rather than just
transferring any data from one origin (the opaque) to the new one and then
deinit' the opaque one (which is what results in user-after-free), the new
origin simply maintains a list of opaque origins it has "taken-over"and is
responsible for freeing it (in its own deinit). This ensures that any allocation
made in the opaque origin remain valid.
When a CDP command with an unrecognized domain (e.g. `NonExistent.method`)
was sent, the error response was correctly returned but the connection
died immediately after. This happened because dispatch() re-returned the
error after sending the error response, which propagated up through
processMessage() → handleMessage() where `catch return false` closed
the WebSocket connection.
Now the error is only propagated if sendError itself fails (e.g. broken
pipe). Otherwise dispatch() returns normally and the read loop continues.
Fixes#1843
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This removes the BufferPool. The BufferPool was per-ScriptManager and only
usable for the response. The ArenaPool is shared across pages and threads, so
can provide much better re-use. Furthermore, the ArenaPool provides an
Allocator, so that a Script's URL or inline content can be owned by the arena/
script itself, rather than the page arena.
Per the HTML spec, browsers should detect charset from <meta> tags
in the first 1024 bytes of a document when the HTTP Content-Type
header doesn't specify one.
Adds Mime.prescanCharset() which scans for:
- <meta charset="X">
- <meta http-equiv="Content-Type" content="...;charset=X">
Integrates into the page loading flow to set the detected charset
on the Mime when no explicit HTTP charset was provided.
Fixes#531
The CDP Accessibility spec defines AXValue.value as always being a
string, but integer values were serialized as JSON numbers. This
breaks CDP clients with strict deserialization (e.g., Rust serde).
Fixes#1822
Depends on https://github.com/lightpanda-io/zig-v8-fork/pull/160
Improves postMessage support, specifically for use across frames. This commit
also addresses a few other issues (identified while implementing this).
1 - Since macrotasks can schedule more macrotasks, we need to check the time-to-
next microtask after all microtasks have completed.
2 - frame's onload callback is triggered from the frame's context, but has to
execute on the parents contet.
Puppeteer's page.setCookie() internally calls Network.deleteCookies twice
before setting a cookie. The second call includes a partitionKey field for
CHIPS (partitioned cookies), which caused Lightpanda to return NotImplemented.
Since Lightpanda doesn't support partitioned cookies, we now silently ignore
the partitionKey parameter and proceed with the cookie operation based on
name/domain/path matching.
This change affects:
- Network.deleteCookies: no longer rejects requests with partitionKey
- Network.setCookie (via setCdpCookie): no longer rejects cookies with partitionKey
Fixes#1818
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The reallocation_count counter was being incremented regardless of whether
the resize/remap operations succeeded. This led to inaccurate memory
allocation statistics.
- resize: Only increment when rawResize returns true (success)
- remap: Only increment when rawRemap returns non-null (success)
This fixes the TODO comments that were present in the code.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1 - When Target.setAutoAttach is called, send the `Target.attachedToTarget`
event before sending the response. This matches Chrome's behavior and
it stops playwright from thinking there's no target and making extra calls,
e.g. to Target.attachedToTarget.
2 - Use the same dummy frameId for all startup messages. I'm not sure why we
have STARTUP-P and STARTUP-B. Using the same frame (a) makes more sense to
me (b) doesn't break any existing integration tests, and (c) improves this
scenario: https://github.com/lightpanda-io/browser/issues/1800
Dynamic scripts have script.async == true by default (we handled this correctly
in the ScriptManager, but we didn't return the right value when .async was
accessed).
Inline scripts only consider direct children, not the entire tree.
Empty inline scripts are executed at a later time if text is inserted into them
Loading `sub 1.html` has a side effect - it increments window.top..sub1_count).
So it should be used careful. It was being used in `about_blank_renavigate` as
a placeholder which _should_ not get navigated, but there's no strict guarantee
about when it gets canceled.
