All global objects current need to be event targets so that they
can have events dispatched to them. This allows for removing of
verify_cast for these global objects.
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.
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.
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.
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.
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.
When attempting to set `HTMLProgressElement.max` to a value not greater
than 0, we were previously setting the value to 1. We now retain the
previous value.
This change ensures that the correct default value of 0 is used and
that values greater than 2147483647 will fall back to the default value.
It also splits the display size concept into a separate method, as
this isn't supposed to be used when getting the IDL property.
Attempting to set `HTMLInputElement.size` to 0 via IDL now throws an
IndexSizeError DOMException. Attempting to set it to a value larger
than 2147483647 results in it being set to the default value.
To check whether a NavigationParams is null, we have to check whether
it's `Empty` or `NullWithError`. Instead, we can merge both of these
possible variants into an optional error. If `NullOrError` has no
value it's null, otherwise it contains an error message.
If `HTMLMarqueeElemnt.scrollAmount` or `HTMLMarqueeElemnt.scrollDelay`
is set to a value larger than 2147483647, then it should be set to its
default value.
