Interfaces with a LegacyNamespace extended attribute should have their
constructors defined on the namespace identified by the LegacyNamespace
attribute value.
This is used by WebAssembly IDL files. For now, we mostly use this for
error messages and cache keys (to ensure compatibility with existing
code as WebAssembly is ported to IDL).
For example, consider the attribute:
interface Element {
[PutForwards=value] readonly attribute DOMTokenList classList;
}
When `classList` is set, we should instead set the attribute `value` on
the `classList` attribute of the Element interface.
Don't try to reserve capacity for a variadic arguments list unless we
actually have enough arguments to fill it with anything. Otherwise we
may overflow to an extremely large size if, e.g., the argument count
is 0 and the start of the variadic arguments is index 1.
We can always read the basic format information (sample rate, bit depth,
etc.), but we will also print artist, album, and title if available in
the metadata.
Similar to POSIX read, the basic read and write functions of AK::Stream
do not have a lower limit of how much data they read or write (apart
from "none at all").
Rename the functions to "read some [data]" and "write some [data]" (with
"data" being omitted, since everything here is reading and writing data)
to make them sufficiently distinct from the functions that ensure to
use the entire buffer (which should be the go-to function for most
usages).
No functional changes, just a lot of new FIXMEs.
Before, some loader plugins implemented their own buffering (FLAC&MP3),
some didn't require any (WAV), and some didn't buffer at all (QOA). This
meant that in practice, while you could load arbitrary amounts of
samples from some loader plugins, you couldn't do that with some others.
Also, it was ill-defined how many samples you would actually get back
from a get_more_samples call.
This commit fixes that by introducing a layer of abstraction between the
loader and its plugins (because that's the whole point of having the
extra class!). The plugins now only implement a load_chunks() function,
which is much simpler to implement and allows plugins to play fast and
loose with what they actually return. Basically, they can return many
chunks of samples, where one chunk is simply a convenient block of
samples to load. In fact, some loaders such as FLAC and QOA have
separate internal functions for loading exactly one chunk. The loaders
*should* load as many chunks as necessary for the sample count to be
reached or surpassed (the latter simplifies loading loops in the
implementations, since you don't need to know how large your next chunk
is going to be; a problem for e.g. FLAC). If a plugin has no problems
returning data of arbitrary size (currently WAV), it can return a single
chunk that exactly (or roughly) matches the requested sample count. If a
plugin is at the stream end, it can also return less samples than was
requested! The loader can handle all of these cases and may call into
load_chunk multiple times. If the plugin returns an empty chunk list (or
only empty chunks; again, they can play fast and loose), the loader
takes that as a stream end signal. Otherwise, the loader will always
return exactly as many samples as the user requested. Buffering is
handled by the loader, allowing any underlying plugin to deal with any
weird sample count requirement the user throws at it (looking at you,
SoundPlayer!).
This (not accidentally!) makes QOA work in SoundPlayer.
headless-browser currently uses its own PageClient to load web pages
in-process. Due to this, it also needs to set up a whole bunch of other
objects needed to run LibWeb, e.g. image decoders, request servers, etc.
This changes headless-browser to instead implement a WebView to launch
WebContent out-of-process. This implementation is almost entirely empty,
but can be filled in as-needed. For example, we may want to print
JavaScript console messages.
At the moment, all it can do is read all image formats that LibGfx can
read and save to any image format that LibGfx can write (currently bmp,
png, qoi).
Currently, it drops all image metadata (including color profiles).
Over time, this could learn tricks like keeping color profiles,
converting an image to a different color profile, cropping out a part of
an image, and so on.
"image" was an alias for "qemu-image".
I want to add an `image` userland utility, which clashes with that
shortname.
So remove the existing "image" target. It was just an alias for
"qemu-image".
If you use serenity.sh to build, nothing changes. This only affects you
if you run ninja manually -- you now have to say `ninja qemu-image` to
build the disk image.
Commit: 2c84466ad8 ("Kernel/Storage: Introduce new boot device
addressing modes") changed the way we pass the boot device parameter.
That commit missed updating boot parameter in the run.sh script for NVMe
boot devices.
We should be able to run this locally, as long as ENABLE_LAGOM_LADYBIRD
is true, or if building ladybird from the ladybird source directory.
This removes a special case from the Lagom CI yml file.
Add some prose to the introduction of Lagom about how we use it. Also,
move the section on including Lagom in other projects above the fuzzer
documentation.
Remove the explicit cmake commands from the Fuzzer documentation, as the
script should be the source of truth.
When an IDL file has #imports and the IDL interface exposes an iterator,
the bindings generator would generate #include statements missing the
class name of the iterator in the form 'LibWeb/{namespace}/Iterator'.
This change only generates the iterator #include statement for the top
interface that is the iterator.
These are treated differently as the interface members are placed on the
object itself, not its prototype.
As the object itself still needs to be hand-written code, and we can no
longer fully hide the gnarly generated code in the prototype object,
these now generate a 'mixin' class that is added to the actual object
through inheritance.
https://webidl.spec.whatwg.org/#Global
The Window object is massive, so let's do the conversion to IDL step
by step. First up: getting rid of the manual constructor and prototype
definitions, which can be generated from an empty `interface Window`.
This relied on pulling the current realm from the main thread VM, which
requires an execution context to be on the VM's stack. This heavily
relied on the dummy execution context that is always on the stack, for
example, when parsing the UA style sheets where no JavaScript is
running.
