1. Double buffer to_load list so that load callback which register more loadable
elements don't invalid the list while we're iterating
2. Switch to debug-only assertion for opaque origin. Not clear how this
assertion is failing, but isn't worth failing release builds for it.
3. on worker terminate, don't remove worker from page tracking. This results in
a leaking context, which causes numerous problems.
4. On page.init error, cleanly shutdown context
Fetch is owned by response.arena (a) we need to clear the flag before freeing
the arena and (b) there's no point in clearing the flag at all, since the
memory is freed.
In order for an API to be supported by workers, their dependency on *Page has
to be removed. To keep this PR smaller, we're only converting a minimum number
of APIs from Page to Execution. All other APIs should not be exposed to the
worker (better to get a FormData undefined than to try to segfault trying to
execute FormData without a page).
Turns out you can embed multiple contexts within a snapshot. So our snapshot
now contains the Page context (as before) but also the Worker context. This
gives us the performance benefit of snapshots and makes context creation for
pages and workers much more similar.
We'll have two types of contexts: one for pages and one for workers. They'll
[probably] both be js.Context, but they'll have distinct FunctionTemplates
attached to their global. The Worker template will only contain a small subset
of the main Page's types, along with 1 or 2 of its own specific ones.
The Snapshot now creates the templates for both, so that the Env contains the
function templates for both contexts. Furthermore, having a "merged" view like
this ensures that the env.template[N] indices are consistent between the two.
However, the snapshot only attaches the Page-specific types to the snapshot
context. This allows the Page-context to be created as-is (e.g. efficiently).
The worker context will be created lazily, on demand, but from the templates
loaded into the env (since, again, the env contains templates for both).
A Worker has no page. So any API that is accessible to a worker cannot take
a *Page parameter. Such APIs will now take a js.Execution which the context
will own and create from the Page (or from the WorkerGlobalScope when that's
created).
To test this, in addition to introducing the Execution, this change also updates
URLSearchParams which is accessible to Worker (and the Page obviously). This
change is obviously viral..if URLSearchParams no longer has a *Page but instead
has an *Execution, then any function it calls must also be updated.
So some APIs will take a *Page (those only accessible from a Page) and some will
take an *Execution (those accessible from a Page or Worker). I'm ok with that.
A lot of private/internal functions take a *Page, because it's simple, but all
they want is a call_arena or something. We'll try to update those as much as
possible. The Page/Execution being injected from the bridge is convenient, but
we should be more specific for internal calls and pass only what's needed.
Refactor `Verifier.zig` to use shared helpers for DOM property checks.
Move `substituteEnvVars` tests to `browser/tools.zig` and remove
redundant debug prints in `Agent.zig`.
Roll back message history on failed self-heal attempts to prevent
context pollution. Cap console messages at 1000 to prevent memory
exhaustion and add a helper to drain the message buffer. Refactor
system prompt initialization into a shared helper function.
- Add heap fallback for `Recorder` when fixed buffers overflow.
- Replace global atomic `agent_failed` with a local variable in `main.zig`.
- Fix `UnkownOption` typo in `Config.zig`.
- Add `Verifier` tests and debug logging for navigations.
- Add memory usage TODO and pointer arithmetic comments in `Agent.zig`.
