@import("lightpanda") where needed.
Would also like to do this for String, Page, Session and js which all stand out
as types that are use across the codebase.
I know that a few devs are doing this in new work and I haven't heard anyone
voice an objection.
Allow mapping js input to a js.String (previously, had to be either a []const u8,
an SSO, or a js.Value). Allow compileFunction to be called directly with a
js.String.
Follow up on https://github.com/lightpanda-io/browser/pull/2179 to remove
the remaining "legacy" async tests (I didn't realize there were only 2 more
files, should have done it all in that commit). Also, slightly improve how
these async tests work in Chrome/FF.
The HTML spec defines `TimerHandler` as `Function or DOMString`, and
the string form is still widely used by legacy sites and server-rendered
pages (e.g. clocks that do `setInterval("updateTime()", 1000)`).
Previously the binding signature required `js.Function.Temp`, so passing
a string threw `TypeError: invalid argument` and aborted page scripts.
Accept `js.Value.Temp` instead, then resolve the handler per spec:
* Function -> persist as-is (unchanged behavior).
* String -> compile as the body of an anonymous function via
`Local.compileFunction`, mirroring what the existing
`Context.stringToPersistedFunction` helper does for
HTML attribute event handlers.
* otherwise -> `InvalidArgument` (TypeError, same as before).
Tests added to window/timers.html:
* setTimeout(string) runs the compiled code.
* setInterval(string) fires at least once and is cancellable.
* non-function / non-string handler still throws TypeError.
Spec: https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers
Document.writeln was not registered on the DOM prototype, so legacy
scripts that rely on it (e.g. script loaders that inject <script> tags
via `document.writeln`) crashed with `document.writeln is not a
function` and prevented the rest of the page from running.
Per HTML spec, writeln runs the document write steps with the joined
argument text followed by a U+000A LINE FEED character. Implement it
by sharing the existing write pipeline so all InvalidStateError and
parser behavior is identical to write().
Tests added to document/write.html covering:
- writeln appends a trailing newline text node after the written nodes
- multiple arguments are concatenated before the newline is appended
Spec: https://html.spec.whatwg.org/multipage/dynamic-markup-insertion.html#dom-document-writeln
Closes#2166
The Linux release binary is linked against glibc, so musl-based distros
(Alpine and similar) hit 'cannot execute: required file not found' on
first run because the glibc dynamic linker is missing.
Adds a note to the install section directing Alpine users to a
glibc-based base image or the build-from-sources path.
This commit was focused on making small changes to cookie parsing in order to
improve a handful of WPT cases.
Protects against nameless cookies that have a value with certain prefixes (e.g.
`__Secure-`) which could be pased into an incorrect prefix.
It allows tabs in cookie names/values.
It enforces that certain prefix have certain settings.
Along the way:
- Added window.origin
- Ensure URL passed to Request is escaped
- Added log on fetch error
- made --dump wpt only list non-passing results
Some WPT tests need to interact with the browser in a way that isn't possible
with web apis. Browsers need to expose a way for tests to do this and then use
the testdriver-vendor.js to hook into these special WPT actions.
This commit sets up the infrastructure for supporting this and includes
the delete_all_cookies functionality needed by various cookie tests (e.g.
/cookies/attributes/attributes-ctl.sub.html).
A new compilation flag, `-Dwpt_extensions`, can be specified. When specified
a `window.webdriver` accessor is defined and a `WebDriver` type is exposed.
Note that, while I only implemented delete_all_cookies for now, I've seen other
tests fail because of missing vendor-specific implementation.
Gives the same treatment to Blob as https://github.com/lightpanda-io/browser/pull/2171
gave to Response.
Creating a blob from JS and creating a blob internally is different enough that
they now share little, and the ergonomics for creating a blob internally are
better / simpler.
Conversely, initializing a Response and Blob from a js.Value now share a
`js_val.toStringSmart()` which can probably be used in other places. Unlike
`toString()` which behaves like JavaScript (e.g. array_buffer.toString() ->
"[object ArrayBuffer]"), `toStringSmart` understands buffers and blobs.
Prunes hidden subtrees from the accessibility tree and implements
accessible name resolution via labels. Adds the `labels` property
to labellable HTML elements.
This commit fixes a few serious issues with the Websocket implementation.
1 - libcurl recursive api calls
Creating a Websocket instance from within a libcurl callback results in libcurl
failing with a RecursiveApiCall error. I fixed this more generally by adding a
`ready_queue` which connections can use when the `HttpClient` is performing
actions. Once `perform` ends, this new `ready_queue` is processed. There might
be a more holistic solution to this (we seem to run into RecursiveApiCall
everywhere), but since HttpClient is going through heavy changes, this seemed
like the smallest possible change to fix it.
2 - "load" blocking
Load and IdleNetwork notifications should not block on Websocket connections. To
solve this, `HttpClient` now ha `http_active` and `ws_active` to replace `active`.
Only `http_active` is used for things like "load" triggering.
3 - The above change made the Runner's job more complicated. It used to be
binary: you either have active connections or not. Now there are different types
of active connections. To keep it simple, and I think probably more correct,
the "done-ness" (based on the `wait` parameter) is now independent of active
(or not) network activity. If the page's `load_state == .complete`, then the
`wait == .done` is considered successful, whether or not we have active
connections.
4 - As a consequence of the above, and seemingly unrelated to all of these
changes, a number of html tests now use the "new" robust async framework. Most
of these tests were using the `testing.onload` (aka `testing.eventually`) which
had somewhat...unclear semantics. These tests passed more of a consequence of
how we processed a page and being very simple (e.g. just needing 1 micro or
macrotask tick). But `eventually` never worked for more complicated cases, and
the previous `testing.async` didn't work well. Now, the test runner waits for
.load (which, as per #3, can fire more aggressively), which caused many
`eventually` tests to fail. Moving these tests to the new `async` is more
robust and works with the new aggressive "load".
We've seen this sort of thing before - an assumption we make about the state of
the DOM through a transition is broken by CustomElement callbacks.
Here we see replaceChild which (a) inserts the new nodes and (b) removes the
old one. As part of removing, our page.removeNode has an assertion that the
child belongs to the parent. This is a guarantee that the Page is asking the
caller (Node.replaceChild in this case) to make. But, if the node being inserted
is a custom element, it can have a callback so step (a) can cause changes to
the document, including removing/moving the node being replaced.
TL;DR - CustomElement callbacks means that we have to check that the child to
be replaced is still a child of the parent after our insert.
