This currently only applies to property-level calculation contexts, more
work to be done to generate accepted ranges for other calculation
contexts (e.g. within transformation functions, color functions, etc)
The TrustedHTML interface represents a string that a developer can
confidently insert into an injection sink that will render it as HTML.
These objects are immutable wrappers around a string, constructed via a
TrustedTypePolicy’s createHTML method.
This reverts 0e3487b9ab.
Back when I made that change, I thought we could make our StyleValue
classes match the typed-om definitions directly. However, they have
different requirements. Typed-om types need to be mutable and GCed,
whereas StyleValues are immutable and ideally wouldn't require a JS VM.
While I was already making such a cataclysmic change, I've moved it into
the StyleValues directory, because it *not* being there has bothered me
for a long time. 😅
These will be used for the mask-repeat property as well in an upcoming
commit, hence the more generic names. Also, this more closely matches
the names used in the spec.
This has quite a lot of fall out. But the majority of it is just type or
UDL substitution, where the changes just fall through to other function
calls.
By changing property key storage to UTF-16, the main affected areas are:
* NativeFunction names must now be UTF-16
* Bytecode identifiers must now be UTF-16
* Module/binding names must now be UTF-16
Many wpt test on trusted-types relay on this class being defined to even
begin the test as it declares some event handlers.
This is not really an implementation but the most basic setup needed to
run the tests.
This adds a new IDL type, Utf16DOMString. This is the same as DOMString,
except it is UTF-16. This type is temporary - we will want DOMString to
be UTF-16 by default once we've ported enough of LibWeb.
To make this support easier, some string IDL generator handling is moved
directly into `generate_to_string` from the call sites.
flatpak-builder doesn't respect .gitignore when creating its local build
directory, so we need to explicitly skip potentially large ignored
directories to avoid bloating the flatpak build directory during builds.
This uses a `foo>bar` notation in the `valid-identifiers` field of
Properties.json, to say "replace `foo` with `bar`".
The motivation here is to avoid calling `parse_css_value_for_property()`
inside the per-property switch in `parse_css_value()`. Eventually we'll
need to be able to call that switch from
`parse_css_value_for_properties()` so that shorthands can make use of
any bespoke parsing code to parse their longhands.
We now clean up installed helper tools, includes from dependencies, and
pkgconfig/CMake files. This decreases the size of the flatpak from
~206MiB to ~150 MiB on my machine.
The manifest is also mostly clean of linter warnings from the
flatpack-builder manifest linter, with the exception of the overly broad
session bus policy.
The docs at https://docs.flathub.org/docs/for-app-authors/linter list a
method for selecting the correct session bus policies, but it is unclear
how to actually get the full set.
On FreeBSD some symbols like `environ` or `__progname` are not exported
anywhere and are filled in by the dynamic loader. `environ` is
a special case because we make use of it explicitly so we need to mark
it a weak symbol so the linker doesn't complain.
Some shorthand properties work differently to normal in that mapping of
provided values to longhands isn't necessarily 1-to-1 and depends on the
number of values provided, for example `margin`, `border-width`, `gap`,
etc.
These properties have distinct behaviors in how they are parsed and
serialized, having them marked allows us to implement theses behaviors
in a generic way.
No functionality changes.
Our currently implementation of structured serialization has a design
flaw, where if the serialized/transferred type was not used in the
destination realm, it would not be seen as exposed and thus we would
not re-create the type on the other side.
This is very common, for example, transferring a MessagePort to a just
inserted iframe, or the just inserted iframe transferring a MessagePort
to it's parent. This is what Google reCAPTCHA does.
This flaw occurred due to relying on lazily populated HashMaps of
constructors, namespaces and interfaces. This commit changes it so that
per-type "is exposed" implementations are generated.
Since it no longer relies on interface name strings, this commit
changes serializable types to indicate their type with an enum,
in line with how transferrable types indicate their type.
This makes Google reCAPTCHA work on https://www.google.com/recaptcha/api2/demo
It currently doesn't work on non-Google origins due to a separate
same-origin policy bug.
Introduces a few ad-hoc modifications to the DAFSA aimed to increase
performance while keeping the data size small.
- The 'first layer' of nodes is extracted out and replaced with a lookup
table. This turns the search for the first character from O(n) to O
(1), and doesn't increase the data size because all first characters
in the set of named character references have the
values 'a'-'z'/'A'-'Z', so a lookup array of exactly 52 elements can
be used. The lookup table stores the cumulative "number" fields that
would be calculated by a linear scan that matches a given node, thus
allowing the unique index to be built-up as normal with a O(1) search
instead of a linear scan.
- The 'second layer' of nodes is also extracted out and searches of the
second layer are done using a bit field of 52 bits (the set bits of
the bit field depend on the first character's value), where each set
bit corresponds to one of 'a'-'z'/'A'-'Z' (similar to the first
layer, the second layer can only contain ASCII alphabetic
characters). The bit field is then re-used (along with an offset) to
get the index into the array of second layer nodes. This technique
ultimately allows for storing the minimum number of nodes in the
second layer, and therefore only increasing the size of the data by
the size of the 'first to second layer link' info which is 52 * 8 =
416 bytes.
- After the second layer, the rest of the data is stored using a
mostly-normal DAFSA, but there are still a few differences:
- The "number" field is cumulative, in the same way that the
first/second layer store a cumulative "number" field. This cuts
down slightly on the amount of work done during the search of a
list of children, and we can get away with it because the
cumulative "number" fields of the remaining nodes in the DAFSA
(after the first and second layer nodes were extracted out) happens
to require few enough bits that we can store the cumulative version
while staying under our 32-bit budget.
- Instead of storing a 'last sibling' flag to denote the end of a
list of children, the length of each node's list of children is
stored. Again, this is mostly done just because there are enough
bits available to do so while keeping the DAFSA node within 32
bits.
- Note: Together, these modifications open up the possibility of
using a binary search instead of a linear search over the
children, but due to the consistently small lengths of the lists
of children in the remaining DAFSA, a linear search actually seems
to be the better option.
The new data size is 24,724 bytes, up from 24,412 bytes (+312, -104 from
the 52 first layer nodes going from 4-bytes to 2-bytes, and +416 from
the addition of the 'first to second layer link' data).
In terms of raw matching speed (outside the context of the tokenizer),
this provides about a 1.72x speedup.
In very named-character-reference-heavy tokenizer benchmarks, this
provides about a 1.05x speedup (the effect of named character reference
matching speed is diluted when benchmarking the tokenizer).
Additionally, fixes the size of the named character reference data when
targeting Windows.
The `shorthands_for_longhand`, `longhands_for_shorthand`, and
`expanded_longhands_for_shorthand` methods can be pretty hot in
profiles where we serialize a lot of CSS properties.
By returning a const reference to a static vector instead of allocating
and returning a new vector every time we can avoid a decent amount of
work.
Overall runtime for the particularly serialization heavy
wpt.live/css/cssom/cssom-getPropertyValue-common-checks.html
decreased by ~20% comparing before and after this change.
This adds an overlay port for curl that adds the features required for
HTTP/3.
This is not quite compatible with the upstream vcpkg.json, because
enabling HTTP/2 makes it use the default SSL backend, which is
sectransp for macOS and schannel on Windows. These backends are not
compatible with ngtcp2. Additionally, we can not build curl with
multiple SSL backends when using ngtcp2.
I couldn't find a way to selectively disable/enable dependencies based
on what features are enabled, so I made HTTP/2 pick OpenSSL in our
overlay port. Upstream vcpkg will likely want to support wolfSSL and
GnuTLS backends for ngtcp2, so they'll be additional work to get this
into upstream.
We often want to identify a property, but if we have a PropertyID we
don't want to have to convert it to a string to then convert it back
again. However, custom properties don't have a useful PropertyID. So,
here's a type with a verbose name.
This build depends on the KDE Flatpak SDK, and builds any missing
dependencies manually as source modules.
The flatpak can be built with the following command:
```sh
flatpak-builder --user --force-clean --install-deps-from=flathub \
--ccache --repo=Build/repo --install Build/flatpak \
Meta/CMake/flatpak/org.ladybird.Ladybird.json
```
After building, the flatpak can be run with:
```sh
flatpak run --user --devel org.ladybird.Ladybird
```
If there are issues launching RequestServer, the .pid and .sock files
under $XDG_RUNTIME_DIR may need removed.
```sh
flatpak run --user --command=sh --devel org.ladybird.Ladybird
rm -f $XDG_RUNTIME_DIR/Ladybird.*
```
These files are lifted from the ladybird-gtk4 repository and adapted
to work with the Qt UI port. They are installed by default on Linux, but
can be installed via a CMake option on other platforms.
Co-Authored-By: Sergey Bugaev <bugaevc@serenityos.org>
Co-Authored-By: Nicolas Ramz <nicolas.ramz@adevinta.com>
Co-Authored-By: Beckett Normington <beckett@b0ba.dev>
Co-Authored-By: Xexxa <93391300+Xexxa@users.noreply.github.com>
To support this, how we declare logical property aliases has changed.
Instead of `logical-alias-for` being a list of properties, it's now an
object with a `group` and `mapping`. The group is the name of a logical
property group in LogicalPropertyGroups.json. The mapping is which
side/dimension/corner this property is. Hopefully it's self-explanatory
enough.
The generated code is very much a copy of what was previously in
`StyleComputer::map_logical_alias_to_physical_property_id()`, so there
should be no behaviour change.
Initially ClippableAndScrollable was introduced, because we had
PaintableBox and InlinePaintable and both wanted to share clipping and
scrolling logic. Now, when InlinePaintable is gone, we could inline
ClippableAndScrollable implementation into PaintableBox.
We haven't required a local copy of the ca-certificates since switching
to OpenSSL as the backend for TLS. Remove the script to download the
PEM file, and update the tests to use the system's CA certificates.
For simplicity, this requires that the setlike Foo class has a
`void on_set_modified_from_js(Badge<Bindings::FooPrototype>)` method.
This will be called after the set is modified from a generated `add()`,
`delete()`, or `clear()` method.
This copies the latest generated code in tree and then removes code
generation for the WebGL rendering contexts. This is because it didn't
add much value, and we can maintain the generated output instead of
both that and the generator itself.
The primary purpose of these is to add bounds checking to older OpenGL
API calls that take arbitrarily sized buffers, but don't know the size
of the buffer and thus rely on the application being certain the buffer
is large enough.
Since these API calls are exposed to arbitrary JS which can make
arbitrarily sized buffers, it is not safe to use the non-robust
variants, as we cannot know the size of the buffer ahead of time, nor
the amount of data required by the API call.
The robust variants provided by ANGLE adds a buffer size parameter,
where it'll calculate the amount of data it needs for that API call
for us and return an error if it's bigger than the given buffer size.
Credit to https://github.com/s41nt0l3xus for finding this during a CTF
and providing a write up that exploits this.
See: 92efbaed6c/gpnctf-2025/WebGL-bird
Add OffscreenCanvas to TexImageSource and CanvasImageSource.
Implement all the necessary features to make it work in all cases where
these types are used.
This implements the basic interface, classes and functions for
OffscreenCanvas. Many are still stubbed out and have many FIXMEs in
them, but it is a basic skeleton.
The libjxl port is required to add the `msvc-remove-libm` patch.
Otherwise LibGfx attempts to link with 'm.lib' which is not valid
for MSVC as the CRT bundles math functions implicitly unlike on Unix
Previously we would incorrectly map these in
`CSSStyleProperties::convert_declarations_to_specified_order`, aside
from being too early (as it meant we didn't maintain them as distinct
from their physical counterparts in CSSStyleProperties), this meant
that we didn't yet have the required context to map them correctly.
We now map them as part of the cascade process. To compute the mapping
context we do a cascade without mapping, and extract the relevant
properties (writing-direction and direction).
Now we won't be building both debug and release for all ports when
using a release, distribution, or sanitizer preset.
Eventually we can use this to build all our ports with clang-cl.exe.
That doesn't work at all out of the box, and needs a bunch of extra
legwork. Likely legwork for every port we build.
Any optional or nullable attribute will end up in an `if/else` branch
when we collect the attribute values, and this is inherently
incompatibly with an `auto {attr}_wrapped = ...` expression. Define the
variable as an `JS::Value` before generating the wrap statement so we
can properly support `toJSON()` for an attribute like:
readonly attribute double? altitude;
These use the `readarray` command which isn't available in the older
version of Bash available on macOS. However, they're also not needed on
macOS, so let's skip them entirely.
Ref: https://github.com/LadybirdBrowser/ladybird/issues/5118
This commit removes the /J flag when compiling with clang-cl. The /J
flag changes the default char type from signed char to unsigned char
which is the opposite of what we want. Now char will be signed, which is
the default on msvc and what we set on linux.
This commit increases compilation speed when using clang-cl. It also
decreases object size as well as adds -fstrict-aliasing to match the
default on linux. The linker option added is not recognized by link.exe
so we enable lld-link by default, which will also increase compilation
speed by itself, and allow for LTO.
