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.
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)
Adds a abortParked (to be used instead of abort for a parked transfer) which
guards against a double-free by setting the state to .completing BEFORE running
the requestFailed callback. Without this, requestFail could itself cause the
transfer to be cleared.
Also added a guard to try to catch double transfer deinit's in Debug. Because
the memory could get re-used between the first and second free, the lack of
failure doesn't prove there is no UAF. But it's cheap to do and debug only.
Cleanup sloppy tests, make sure pages are always closed after page tests - not
before and not never.
Fix a UAF in replaceRootImmediate..if a page is being retired, also retire its
replacement.
Give BrowserContext a Session.PageHandle rather than having a frame_id and re-
implementing PageHandle logic.
Replaces the 1 (+1 inflight) page design of session for an unlimited number of
pages. The main goal is to support a more efficient async goto (1). Without this
commit, async goto has two implementation: multiple browser, which is resource
intensive (thread + isolate per page), bolting it onto sub-frames (like iframe
or popups). The issue with the 2nd version (which I originally suggested) is
that most resources are tied to the Page. So even if an async goto "page" (which
would map to a Frame) is released, most things stay in memory, including the
DOM (page.factory) and the V8::Context.
This new approach adds multiple page support to sessions. The advantage is
pretty clear: the existing memory model (page-tied resources) becomes a strength
of the design, rather than a weakness.
This change is not tirivla, but the diff is inflated by 2 large mechanial
changes, so it isn't _that_ big either. That said, I'd divide this into four
parts.
1 - The old concept of _active/_pending is now baked into the Page itself. A
Page has a `replaces: ?*Page = null` and `replacement: ?*Page = null` field.
2 - Because of #1 above, the Session now just has an `pages: ArrayList(*Page)`.
As much as possible, single-page APIs, like `removePage` no longer exists. We're
trying to present a consistent multi-page API. See #3.
3 - References to *Page and *Frame have always been dangerous. For example,
`lightpanda.fetch` has a block to scope `frame`:
```zig
{
const frame = try session.createPage();
// frame isn't safe to use after navigate, it can be swapped out
_ = try frame.navigate(...)
}
```
While we still hand out *Page and *Frame (user-beware), some of the more
important APIs now take a frame_id which Session can resolve. Furthermore,
createPage now returns a PageHandle which is a safe wrapper around a page/frame.
4 - Two large mechanical changes were made:
a - Many tests were superficially changed to account for new naming or use
a new test-helper to preserve the single-page illusion (because 99% of
tests _are_ single-page)
b - Many CDP changes where `bc.session.currentFrame()` -> `bc.mainFrame()`).
This isn't to say CDP changes are meaningless, but it's mostly 1 change
about how the "main" target/frame_id is tracked (by CDP itself, rather
than the Session) that required a number of superficial changes to
accomodate
`Runner` remains largely single-page focused. Runner and some MCP/Agent tools
continue to be tied to the "currentFrame" or "primaryPage". The Runner is
something I want to address in a follow-up PR, but we need to figure out what
it means to "wait" for multiple pages.
As much as possible, Session becomes multi-page native and has no concept of
a special/first/primary/main page. Users of session become responsible for
tracking pages of interest.
This change is not trivial, but the diff is inflated by 2 large mechanical
changes:
1 - Many tests
(1) https://github.com/lightpanda-io/browser/pull/2759
History.goInner re-derived the fragment-vs-document decision from the raw
entry._url, while navigateInner computes it from the resolved URL. These
diverge when an entry stores a non-canonical URL, queuing a spurious
hashchange (or missing one). Let navigateInner own the decision and queue
the event for all same-document navigations; drop goInner's duplicate.
This is a deprecated API, but it's used in various WPT tests. I don't expect
WPT tests to necessarily improve, but they should get further than just failing
on the setter.
This also includes a change where BroadcastChannel now uses the origin string
rather than the js.Origin identity because BroadcastChannel should be based
on the actual frame's origin...which used to be captured in Context.origin but
which the new document.domain can change.
When "rendering" innerText, we don't care about the visibility of the entire
tree, we just care about the visibilty of the element itself and then all of
it's children. Or, put differently:
```
<div style=display:none>
<div id=x>spice</div>
</div>
<script>
console.log(document.getElementById('x').innerText)
</script>
```
Should still print "spice"..even though 'x' is inside a hidden element. The
original version used the StyleManager's isHidden which fails this test - it
scans all the parents. This new version just considers the visibility of each
element being displayed. This is faster and more correct
Add Element/DocuemntFragment/Document moveBefore. The API is relatively
complicated compared to other node-moving APIs, so there are still some edge
cases. But this implementation should be at a level where having the API fixes
more things than it breaks.