It seems like there are known false positives with thread sanitizer and sqlite.
(There are various references to this in sqlite's wal.c and also possibly
related https://bugzilla.mozilla.org/show_bug.cgi?id=1153409
This adds an app.storage which is a union around configurable storage engine
(currently, only sqlite).
It is _not_ being used anywhere right now. The goal is to get feedback on
the implementation and then move cache to it.
This doesn't expose a generic query API. The goal is that the storage will
expose high level methods, e.g. `cacheGet(req: CacheGetRequest)` and every
storage engine will translate the `storage.CacheGetRequest` as needed.
A thin wrapper around the Sqlite C api is included, e.g. exec(SQL, .{args}) a
`rows` and `row` fetcher. A connection pool is included. By default, an
in-memory DB is currently created. And a `migrations` table with an id of `1`
is created/inserted. I don't imagine needing fancy migratations.
@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".
