When experimenting with different inheritance structures, I ended up
seeing compilation failures whenever a parent class defined a `call`
method. This seems more in line with the rest of the code.
In line with the ShadowRealm proposal changes in the WebIDL spec:
webidl#1437 and supporting changes in HTML spec.
This is required for ShadowRealms as they have no relevant settings
object on the shadow realm, so fixes a crash in the QueueingStrategy
test in this commit.
I believe this is an error in the UI Events spec, and it should be
updated to match the HTML spec (which uses WindowProxy everywhere).
This fixes a bunch of issues already covered by existing WPT tests.
Spec bug: https://github.com/w3c/uievents/issues/388
Note that WebKit has been using WindowProxy instead of Window in
UI Events IDL since 2018:
816158b4aa
We were previously throwing an exception if the generated code was
throwing an exception before it hit the implementation of the interface.
Instead, we are meant to catch any exception, and wrap that in a
rejected promise.
For example, this was impacting the fixed test in this commit as an
exception was being thrown when invoking WebIDL::convert_to_int<T>
as the given number was out of range, and the [EnforceRange]
extended attribute decorates that attribute.
This same type of case is seen for a few tests in WPT.
Resulting in a massive rename across almost everywhere! Alongside the
namespace change, we now have the following names:
* JS::NonnullGCPtr -> GC::Ref
* JS::GCPtr -> GC::Ptr
* JS::HeapFunction -> GC::Function
* JS::CellImpl -> GC::Cell
* JS::Handle -> GC::Root
The CSSOM spec tells us to potentially add up to three different IDL
attributes to CSSStyleDeclaration for every CSS property we support:
- A camelCased attribute, where a dash indicates the next character
should be uppercase
- A camelCased attribute for every -webkit- prefixed property, with the
first letter always being lowercase
- A dashed-attribute for every property with a dash in it.
Additionally, every attribute must have the CEReactions and
LegacyNullToEmptyString extended attributes specified on it.
Since we specify every property we support with Properties.json, we can
use that file to generate the IDL file and it's implementation.
We import it from the Build directory with the help of multiple import
base paths. Then, we add it to CSSStyleDeclaration via the mixin
functionality and inheriting the generated class in
CSSStyleDeclaration.
This allows us to specify multiple base paths to look for imported IDL
files in. This will allow us to import IDL files from sources and from
the Build directory (i.e. for generated IDL files).
Now that the heap has no knowledge about a JavaScript realm and is
purely for managing the memory of the heap, it does not make sense
to name this function to say that it is a non-realm variant.
The main motivation behind this is to remove JS specifics of the Realm
from the implementation of the Heap.
As a side effect of this change, this is a bit nicer to read than the
previous approach, and in my opinion, also makes it a little more clear
that this method is specific to a JavaScript Realm.
We will want to re-inform WebContent of the system visibility state when
we create a new process after a crash. This changes the IPC to just send
the enum value directly, instead of a boolean, so that we can just store
that enum value directly on the ViewImplementation class.
The `[[GetOwnProperty]]` internal method invocation in
`OrdinarySetWithOwnDescriptor` was being invocated again with the same
parameters in the `[[DefineOwnProperty]]` internal method that is also
later called in `OrdinarySetWithOwnDescriptor`.
The `PlatformObject.[[DefineOwnProperty]]` has similair logic.
This change adds an optional parameter to the `[[DefineOwnProperty]]`
internal method so the results of the previous `[[GetOwnProperty]]`
internal method invocation can be re-used.
By making use of the known set of supported dictionary names in that
overload set. Note that this list is typically very small (the max that
we have currently is 1).
It would be strange for the IDL to be defined as such, so instead of
leaving a FIXME comment, let's just verify that this doesn't happen in
practise incase it does end up happening in reality.
This change also removes as much direct use of JS::Promise in LibWeb
as possible. When specs refer to `Promise<T>` they should be assumed
to be referring to the WebIDL Promise type, not the JS::Promise type.
The one exception is the HostPromiseRejectionTracker hook on the JS
VM. This facility and its associated sets and events are intended to
expose the exact opaque object handles that were rejected to author
code. This is not possible with the WebIDL Promise type, so we have
to use JS::Promise or JS::Object to hold onto the promises.
It also exposes which specs need some updates in the area of
promises. WebDriver stands out in this regard. WebAudio could use
some more cross-references to WebIDL as well to clarify things.
This change completes handling for all ARIA properties defined in the
current ARIA spec — by adding handling for the following properties:
- aria-braillelabel
- aria-brailleroledescription
- aria-colindextext
- aria-description
- aria-rowindextext
