1. Add a bunch of initXYZEvent functions, and fix the overload of initTextEvent
2. Add a number of missing (mostly legacy) accessors, e.g. uievent.getWhich()
3. CompositionEvent inherits from UIEvent, not Event
4. Give every accessor get/set a name. E.g the "name" of script.src is
"get script" and "set script".
Currently, we return a dummy `WebGLRenderingContext`. But this type implements
virtually nothing. From MDN: "If the context identifier is not supported null is
returned."
Now, normally we like to move things along as much as we can. Returning
`WebGLRenderingContext` lets us know the next thing the code needs. But in this
case, it seems to be problematic. At least some code is defensive around a null
value from getContext('webgl'), but once we return an instance, it expects it
to work correctly. This is what causes https://github.com/features/copilot to
enter an endless JS loop.
Per RFC 7231 §7.1.2, when a 3xx response carries a Location header
without a fragment, the user agent must process the redirect as if
the value inherited the fragment of the request URL. URL.resolve
follows RFC 3986 §5.3 which drops the base fragment, so handleRedirect
now reattaches the original fragment when the resolved target has none.
Closes#2263
The JsApi binding for Location.prototype declared `pathname` and `search`
as read-only accessors (`null` setter), so assigning either had no
observable effect — the URL was never re-parsed and no navigation was
queued. Per HTML Living Standard §7.4.4.5.5/§7.4.4.5.6, both setters
must run the URL parser against a copy of the current URL and then
"Location-object navigate" to the result.
Add `setPathname` / `setSearch` member functions that mirror the
existing `setHash` shape: compute the new full URL via the matching
helper in `src/browser/URL.zig` and forward to `Frame.scheduleNavigation`
with `kind = .push` (matches Chrome's history-handling for these
setters). Wire them into the `pathname` / `search` accessors in place
of the previous `null` setters.
Closes#2256
Improvement to https://github.com/lightpanda-io/browser/pull/2246
In that PR, the check for `v8__Isolate__IsExecutionTerminating` guarded
runMicrotasks from running when the execution was terminated, but what if
termination happens immediately after? This adds a mutex to ensure that the
isolate cannot be terminated while microtasks are being processed.
The empty Zig anonymous struct `.{}` serializes to `[]` (tuple → JSON
array), not `{}`. The dispatch path's `InputParams.jsonParse` requires
the params field to begin with `object_begin`, so the previous test
fixtures hit `error.UnexpectedToken` → `error.InvalidJSON` instead of
exercising the production code paths.
Switch the two empty-params test cases to raw JSON string literals,
which the testing helper passes through unchanged (string literals are
pointer types and skip `std.json.Stringify.valueAlloc`). The production
code paths under test are unchanged.
`Network.clearBrowserCookies` had an inverted-logic guard that returned
`InvalidParams` whenever the caller included a `params: {}` field — which
most CDP libraries (chrome-remote-interface, chromedp, etc.) do
unconditionally. The CDP spec defines no parameters for the method, but
JSON-RPC convention is to silently accept extra ones; Chrome and the
sibling `Storage.clearCookies` handler already do. Drop the guard.
`Network.getAllCookies` was missing from the `Network` dispatch enum and
returned `UnknownMethod`. Add a small handler that returns the entire
cookie jar via the existing `CdpStorage.CookieWriter`, mirroring
`Storage.getCookies` minus the `browserContextId` filter (Network
commands are scoped to the current browser context already).
Closes#2254
When Form.requestSubmit() is called without a submitter argument, the
HTML spec defaults the internal submitter variable to the form element
itself (step 2). The subsequent "submit a form element" algorithm then
collapses submitter === form back to submitterButton = null before
constructing the SubmitEvent. We were skipping that collapse and using
the form as the SubmitEvent's submitter, which diverges from Chrome /
Firefox / WPT.
Frame.submitForm now coerces submitter_ to null when it equals the
form element, mirroring the spec algorithm. The form.html fixture
that previously asserted the wrong behavior is updated to assert
.submitter === null per spec.
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#concept-form-submitCloses#2252
Same-URL navigate should always cause a reload. The code that currently prevents
a navigate on fragment change is too loose and treats identical URLs as being
a fragment change..but for it to be considered a fragment change, the fragment
actually has to change.
This improves some WPT compat where tests do:
<iframe></iframe> <--- loads "about:blank"
<script>
document.querySelector('iframe').src = "about:blank"; <--- should load it again
</script>
- Update `ToolExecutor.callEval` to return `EvalResult` for better error handling.
- Swap `ScriptIterator.init` arguments to follow the allocator-first convention.
- Use explicit type syntax for `.init` calls across the agent package.
- Remove redundant `isKnownTool` helper in favor of direct enum conversion.
Runner._wait can iterate for the full opts.ms budget (up to 30s in
fetch, longer in agent tool-use loops). V8 was only nudged to GC on
session/page teardown (Browser.deinit, Page.deinit), so a page that
stays alive while running heavy JS accumulates wrappers and
external-ref'd Zig allocations V8 has no reason to drop. Fire
memoryPressureNotification(.moderate) once per second from the wait
loop.
The main.zig path for `fetch` now captures the *Browser so that
browser.env.terminate() can be called. This is a bit more complex than the serve
path because the Browser owns the Isolate and can't be moved from one thread to
another.
With main having access to the browser, two things are now possible:
1 - We can support a --terminate-ms flag (https://github.com/lightpanda-io/browser/issues/2206)
2 - ctrl-c can correctly stop blocked JavaScript processes
1 is implemented via setitimer to set a timer for SIGALRM, avoiding the need to
add another "watcher" thread, or putting a timer in Network.run.
Was previously using page.arena, but there's no reason to hold this beyond the
point where the page is parsed, and the page can live for quite some time after
the initial load.
Frame.getElementByIdFromNode is the selector engine's fast path for
`#id` queries. It only consulted `_elements_by_id`, while
Document.getElementById and ShadowRoot.getElementById both fall back
to `_removed_ids` + TreeWalker to recover a surviving duplicate after
the first has been removed.
The two APIs could disagree after DOM manipulation that removes a
duplicate-ID element (e.g. Turbo Drive's PageRenderer.replaceBody
doing innerHTML + replaceWith):
document.querySelector('#page-title') => null
document.getElementById('page-title') => <h1>
Dispatch to the existing canonical getElementById on the scope
(ShadowRoot or Document) instead of keeping a third, map-only copy
of the lookup. The two APIs now agree by construction.
