* Options with optional types are introduced to null by default
* Options with boolean types cannot be optional (nullable)
* Options with boolean types are introduced with false by default
* introduce shortcuts for options that can be provided via single dash
* introduce validators; custom parsing logic can be inserted for niche cases
This is to pave the way for introducing a new "Page" container, which will take
over the page lifecycle currently burdening Session. The ultimate goal of that
is to allow the Session to have multiple pages (mostly for better transitions
between pages), which is hard to do now since the Session has so much state.
This rename was aggressive, e.g. currentPage() -> currentFrame() so that, when
the new Page container is added, you won't see "currentPage()" and wonder:
"Does 'currentPage' mean the new Page container, or the Frame (which
used to be called Page)".
Rename page.id -> page._loader_id and propagate the change throughout. This was
my attempt at pretending that page.id (and page._frame_id) weren't CDP-sepcific.
But they are, and it's a lot cleaner to treat them this way. Might seem
unnecessary, but without this, after page -> frame, you'd end up with:
frame.id
frame._frame_id
Which is weird? What is `frame.id` if it isn't the frame id and if that's the
case, what's frame_id? Now it'll be:
frame._loader_id
frame._frame_id
Which removes the ambiguity, makes the CDP code a bit more obvious, and doesn't
try to hide the fact that these are CDP things that, for now at least, pollute
the code a little.
I asked claude to do for the png what it did for the pdf. The savings aren't as
big AND, it isn't as nice as the original.
I'm tempted to say we should keep the original, but I don't feel strongly about
it and maybe saving a few KB is worth it?
With our current "null" cullback, trying to clone a shared buffer crashes. The
callback throws an error.
Fixes a WPT crash:
/html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/blob-data.https.html
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.
