The rules for parsing integers don't specify an upper bound on the
value that can be returned, so the `parse_integer_digits` method can be
used to check whether the given arbitrarily-large StringView is valid
according to these rules. The `parse_integer` and
`parse_non_negative_integer` methods would fail for values larger than
2147483647 when they shouldn't have.
restore() corresponding to ApplyFilters should be called after stacking
context content is painted, not before.
Fixes regression introduced in c94b4316e7
ApplyOpacity internally calls canvas.saveLayer() which requires a
matching canvas.restore() to be called.
Fixes missing header on https://supabase.com/
Setting the `width` or `height` properties of `HTMLCanvasElement` to a
value greater than 2147483647 will now cause the property to be set to
its default value.
ApplyFilter internally calls canvas.saveLayer() which requires a
matching canvas.restore() to be called.
Fixes painting on https://supabase.com/ regressed by
8562b0e33b
This is part of a normative change to the HTML space for WebAssembly JS
module integration and the source phase import proposal, see:
https://github.com/whatwg/html/commit/10ed38ee7
Further changes are required, but this is a start :^)
When the "Consume a component value from input, and do nothing."
step in `Parser::consume_the_remnants_of_a_bad_declaration` was
executed, it would allocate a `ComponentValue` that was then
immediately discarded.
Add explicitly `{}_and_do_nothing` functions for this case that never
allocate a `ComponentValue` in the first place.
Also remove a `(Token)` cast, which was unnecessarily copying a `Token`
as well.
Lazily coercing might have made sense in the past, but since hashing
and comparing requires the `PropertyKey` to be coerced, and since a
`PropertyKey` will be used to index into a hashmap 99% of the time,
which will hash the `PropertyKey` and use it in comparisons, the
extra complexity and branching produced by lazily coercing has
become more trouble than it is worth.
Remove the lazy coercions, which then also neatly allows us to
switch to a `Variant`-based implementation.
To facilitate the implementation of "delete" and all associated
algorithms, split off this piece of `Document` into a separate
directory.
This sets up the infrastructure for arbitrary commands to be supported.
Corresponds to https://github.com/whatwg/html/pull/10683
As part of this, I noticed we incorrectly were setting the "is popup"
flag on the Navigable instead of the BrowsingContext. I've fixed that
and removed the erroneous flag from Navigable.
This lets us move a few Host-related functions (like serialization and
checks for what the Host is) into Host instead of having them dotted
around the codebase.
For now, the interface is still very Variant-like, to avoid having to
change quite so much in one go.
A couple of reasons:
- Origin's Host (when in the tuple state) can't be null
- There's an "empty host" concept in the spec which is NOT the same as a
null Host, and that was confusing me.
Recently reported against the shadow realm proposal after running into
issues with WPT tests.
In a nested shadow realm, the associated realm is a shadow realm, not
the principal realm. One such issue this fixes is a crash when a nested
shadow realm performs an operation which requires the principal settings
object.
There was a bug in the HTML proposal where a synthetic realm settings
object's principal realm was a shadow realm if there were nested shadow
realms, which this assertion catches more directly (rather than later
down the track, where it is used).
We were meant to also assert for this case, but we were previously
returning early.
This is to resolve naming conflicts between the ServiceWorker JS exposed
object and the internal representation of a ServiceWorker which is going
to be stored cross process.
