Previously we were assuming that the attribute return value was never
nullable and going to be returned in an Optional<IntegralType>, causing
complile errors for something such as: `attribute unsigned long?`.
(cherry picked from commit ad32227c833e60c55b0f5460a4f9f9c1631ecd57)
Mirroring the pre-existing `generate_from_integral` function. This will
allow us to fix a bug that all of these if statements have in common -
no handling of nullable types.
This also adjusts the type casted for each integral to fully match that
stated by the spec.
(cherry picked from commit d6243abec3e0f10ddf75a32c8a291f43cbdae169)
USVString attributes Now replace any surrogates with the replacement
character U+FFFD and resolve any relative URLs to an absolute URL. This
brings our implementation in line with the specification.
(cherry picked from commit 335d51d6782c66e7743d773f6f6b6a32a2cb2067)
USVString is defined in the IDL spec as:
> The USVString type corresponds to scalar value strings. Depending on
> the context, these can be treated as sequences of either 16-bit
> unsigned integer code units or scalar values.
This means we need to account for surrogate code points by using the
replacement character.
This fixes the last test in https://wpt.live/url/url-constructor.any.html
(cherry picked from commit aa32bfa4481f6298c99846025394b7bc415ca621)
For a long time, we've used two terms, inconsistently:
- "Identifier" is a spec term, but refers to a sequence of alphanumeric
characters, which may or may not be a keyword. (Keywords are a
subset of all identifiers.)
- "ValueID" is entirely non-spec, and is directly called a "keyword" in
the CSS specs.
So to avoid confusion as much as possible, let's align with the spec
terminology. I've attempted to change variable names as well, but
obviously we use Keywords in a lot of places in LibWeb and so I may
have missed some.
One exception is that I've not renamed "valid-identifiers" in
Properties.json... I'd like to combine that and the "valid-types" array
together eventually, so there's no benefit to doing an extra rename
now.
(cherry picked from commit 6a74b0164423d63904cf5a5b594772b595f57600;
very minorly amended to fix conflict in GenerateCSSKeyword.cpp caused
by #22870, and in libweb_generators.cmake due to us not having
https://github.com/LadybirdBrowser/ladybird/pull/741)
This cherry-picks the CodeGenerators changes from the second commit in
https://github.com/LadybirdBrowser/ladybird/pull/626
We'll want to enable -Wmissing-declarations (gcc) /
-Wmissing-prototypes (lagom) for Lagom too, but that can happen
in a separate PR.
(cherry picked from commit c62240aa80dceddd7e6ba5bf779a56c84ab8c624;
amended to remove half of the changes. Many of them were in
ladybird-only code. Changed commit message.)
C++ will jovially select the implicit conversion operator, even if it's
complete bogus, such as for unknown-size types or non-destructible
types. Therefore, all such conversions (which incur a copy) must
(unfortunately) be explicit so that non-copyable types continue to work.
This is `counter(name, style?)` or `counters(name, link, style?)`. The
difference being, `counter()` matches only the nearest level (eg, "1"),
and `counters()` combines all the levels in the tree (eg, "3.4.1").
(cherry picked from commit 576a4314084e5c3b839006da00dddb16e58b3503)
It turns out we were already generating all the necessary include
statements, and we can simply remove all this goofy code soup that
uses the C preprocessor to speculatively look for include files.
(cherry picked from commit 2daaa22a15c69b89120a64d1144f99ca13ac689c)
This would continually loop on the same interface.
Co-authored-by: Matthew Olsson <matthewcolsson@gmail.com>
(cherry picked from commit e8fe7c0ee3a2cdfe55d0240e06fae288f5be5063)
Following the rules in the algorithm from
https://webidl.spec.whatwg.org/#js-platform-objects, "To Internally
create a new object implementing the interface interface", this change
incorporates the steps to load a prototype from new.target, and write
it to the created instance returned from constructor_impl(). This
mirrors the code for generate_html_constructor(), which incorporates
additional steps needed by Custom Elements.
Bug LadybirdBrowser/ladybird#334
(cherry picked from commit 80cd3712c2c52bf749a19cbd21af0c5c479a87c9)
This implements most of the CloseWatcher API from the html spec.
AbortSignal support is unimplemented.
Integration with dialogs and popovers is also unimplemented.
(cherry picked from commit b216046234560df531e1a32269e5dfa18f8f240c,
manually amended to replace a single `UIEvents::KeyCode::Key_Escape`
with `KeyCode::Key_Escape` in EventHandler.cpp since we don't have
the second commit of https://github.com/LadybirdBrowser/ladybird/pull/86)
This implements a stub ElementInternals object which implements the
shadowRoot getter only.
Also implement attachInternals function.
(cherry picked from commit a65f1ecc375fa02deeab5d0e7ab4702972ffa72e)
Methods and attributes marked with [FIXME] are now implemented as
direct properties with the value `undefined` and are marked with the
[[Unimplemented]] attribute. This allows accesses to these properties
to be reported, while having no other side-effects.
This fixes an issue where [FIXME] methods broke feature detection on
some sites.
(cherry picked from commit 2f5cf8ac204a58dc2a6f722dd95015c6c2fb7a78)
This allows readonly attributes and functions to have a 'FIXME' extended
attribute added to the IDL definition to stub out the function. This
makes debugging web compatibility issues on live sites much easier as a
FIXME message is logged whenever one of these functions or attributes
are called.
Support still needs to be extended to non-readonly attributes (and some
other special cases), but this should allow us to set a big percentage
of the commented out attributes/functions in IDL files to instead use
this extended attribute.
An AudioNode is the fundamental building block used in 'Audio
Contexts'. In our immediate case, the audio node we are working towards
implementing is an oscillating source node.
This was resulting in a whole lot of rebuilding whenever a new IDL
interface was added.
Instead, just directly include the prototype in every C++ file which
needs it. While we only really need a forward declaration in each cpp
file; including the full prototype header (which itself only includes
LibJS/Object.h, which is already transitively brought in by
PlatformObject) - it seems like a small price to pay compared to what
feels like a full rebuild of LibWeb whenever a new IDL file is added.
Given all of these includes are only needed for the ::initialize
method, there is probably a smart way of avoiding this problem
altogether. I've considered both using some macro trickery or generating
these functions somehow instead.
The prototype header generation was getting a bit long.
This is also a step towards generating code for IDL files only
containing an enum definition without any interface. In that case we
can't put the enum definitions alongside the prototype - there is no
prototype to speak of.
We should never hit this case - so don't generate code for it, and
instead put in a VERIFY_NOT_REACHED.
Also improve the formatting of the generated code to closer match the
serenity code style.
Instead of a cryptic error that occurs due to an interface with no name,
fail early on by explicitly checking that an interface was parsed with a
name.
