This makes it more convenient to use the 'relvant agent' concept,
instead of the awkward dynamic casts we needed to do for every call
site.
mutation_observers is also changed to hold a GC::Root instead of raw
GC::Ptr. Somehow this was not causing problems before, but trips up CI
after these changes.
Returning numbers instead of booleans for the statuses made Ruffle
(through the wgpu crate) think a shader/program failed to compile/link,
as it does a strict type comparison.
Required by https://qwasm2.m-h.org.uk, which adds a custom `name`
attribute to objects it generates. It then gets some of these objects
out with getParameter, and expects the `name` attribute to be there.
This is mostly a development helper, to move all undefined symbols
in shared libraries to link time rather than load time.
At the same time, set --no-allow-shlib-undefined and -z,defs to
further enforce the rule.
Previously, a method with multiple sequence arguments would cause a
compile error, as the same variable name was redeclared when iterating
the sequence for each argument. This change disambiguates these
variable names.
This change fixes the IDLGenerators.cpp implementation of the “If
reflectedTarget's explicitly set attr-element is a descendant of any of
element's shadow-including ancestors” step from the “If a reflected IDL
attribute has the type T?, where T is either Element or an interface
that inherits from Element” case in the HTML spec at
http://whatwg.org/html/#reflecting-content-attributes-in-idl-attributes
This change updates the BindingsGenerator/IDLGenerators.cpp code to
handle reflected non-HTML::AttributeNames content-attribute names, and
to handle such names as-is — including names with dashes.
This change updates the bindings generator for the case defined at
https://html.spec.whatwg.org/#reflecting-content-attributes-in-idl-attributes:element;
that is, the case “If a reflected IDL attribute has the type T?, where T
is either Element or an interface that inherits from Element”.
The change “normalizes” the generator behavior for that case — such that
the generated code expects a getter with a name of the form used in
other cases; e.g., popover_target_element().
Otherwise, without this change, the generator expects a name of the form
get_popover_target_element() for that case.
1. Stop using GC::Root in member variables, since that usually creates
a realm leak.
2. Stop putting OrderedHashMap<FlyString, GC::Ptr> on the stack while
setting these up, since that won't protect the objects from GC.
Some WPT tests expect that if you go out of your way to
Object.getOwnPropertyDescriptor on an interface object and extract
the setter out of it, that they throw when called with no arguments.
When we originally implemented calc(), the result of a calculation was
guaranteed to be a single CSS type like a Length or Angle. However, CSS
Values 4 now allows more complex type arithmetic, which is represented
by the CSSNumericType class. Using that directly makes us more correct,
and allows us to remove a large amount of now ad-hoc code.
Unfortunately this is a large commit but the changes it makes are
interconnected enough that doing one at a time causes test
regressions.
In no particular order:
- Update our "determine the type of a calculation" code to match the
newest spec, which sets percent hints in a couple more cases. (One of
these we're skipping for now, I think it fails because of the FIXMEs
in CSSNumericType::matches_foo().)
- Make the generated math-function-parsing code aware of the difference
between arguments being the same type, and being "consistent" types,
for each function. Otherwise those extra percent hints would cause
them to fail validation incorrectly.
- Use the CSSNumericType as the type for the CalculationResult.
- Calculate and assign each math function's type in its constructor,
instead of calculating it repeatedly on-demand.
The `CalculationNode::resolved_type()` method is now entirely unused and
has been removed.
This reverts commit 76daba3069.
We're going to need separate types for the JS-exposed style values, so
it doesn't make sense for us to match their names with our internal
types.
When applied, corresponding interface object will not be exposed on the
global object, e.g. for the following IDL:
```
Exposed=(Window,Worker), LegacyNoInterfaceObject]
interface ANGLE_instanced_arrays {
};
```
executing `"ANGLE_instanced_arrays" in window` will return `false`.
When message encoding failed for some reason, we'd just swallow the
error without saying a word, and carry on without sending anything.
This led to some very confusing situations.
