diff options
Diffstat (limited to 'dom/docs/webIdlBindings')
| -rw-r--r-- | dom/docs/webIdlBindings/index.md | 2427 |
1 files changed, 2427 insertions, 0 deletions
diff --git a/dom/docs/webIdlBindings/index.md b/dom/docs/webIdlBindings/index.md new file mode 100644 index 0000000000..5554123757 --- /dev/null +++ b/dom/docs/webIdlBindings/index.md @@ -0,0 +1,2427 @@ +# Web IDL bindings + +<div class="note"> +<div class="admonition-title">Note</div> + +Need to document the setup for indexed and named +setters/creators/deleters. + +</div> + +The [Web IDL](https://webidl.spec.whatwg.org/) bindings are generated +at build time based on two things: the actual Web IDL file and a +configuration file that lists some metadata about how the Web IDL should +be reflected into Gecko-internal code. + +All Web IDL files should be placed in +[`dom/webidl`](https://searchfox.org/mozilla-central/source/dom/webidl/) +and added to the list in the +[moz.build](https://searchfox.org/mozilla-central/source/dom/webidl/moz.build) +file in that directory. + +Note that if you're adding new interfaces, then the test at +`dom/tests/mochitest/general/test_interfaces.html` will most likely +fail. This is a signal that you need to get a review from a [DOM +peer](https://wiki.mozilla.org/Modules/All#Document_Object_Model). +Resist the urge to just add your interfaces to the +[moz.build](https://searchfox.org/mozilla-central/source/dom/webidl/moz.build) list +without the review; it will just annoy the DOM peers and they'll make +you get the review anyway. + +The configuration file, `dom/bindings/Bindings.conf`, is basically a +Python dict that maps interface names to information about the +interface, called a *descriptor*. There are all sorts of possible +options here that handle various edge cases, but most descriptors can be +very simple. + +All the generated code is placed in the `mozilla::dom` namespace. For +each interface, a namespace whose name is the name of the interface with +`Binding` appended is created, and all the things pertaining to that +interface's binding go in that namespace. + +There are various helper objects and utility methods in +[`dom/bindings`](https://searchfox.org/mozilla-central/source/dom/bindings) +that are also all in the `mozilla::dom` namespace and whose headers +are all exported into `mozilla/dom` (placed in +`$OBJDIR/dist/include` by the build process). + +## Adding Web IDL bindings to a class + +To add a Web IDL binding for interface `MyInterface` to a class +`mozilla::dom::MyInterface` that's supposed to implement that +interface, you need to do the following: + +1. If your interface doesn't inherit from any other interfaces, inherit + from `nsWrapperCache` and hook up the class to the cycle collector + so it will trace the wrapper cache properly. Note that you may not + need to do this if your objects can only be created, never gotten + from other objects. If you also inherit from `nsISupports`, make + sure the `nsISupports` comes before the `nsWrapperCache` in your + list of parent classes. If your interface *does* inherit from another + interface, just inherit from the C++ type that the other interface + corresponds to. + + If you do need to hook up cycle collection, it will look like this in + the common case of also inheriting from nsISupports: + + ``` cpp + // Add strong pointers your class holds here. If you do, change to using + // NS_IMPL_CYCLE_COLLECTION_WRAPPERCACHE. + NS_IMPL_CYCLE_COLLECTION_WRAPPERCACHE_0(MyClass) + NS_IMPL_CYCLE_COLLECTING_ADDREF(MyClass) + NS_IMPL_CYCLE_COLLECTING_RELEASE(MyClass) + NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION(MyClass) + NS_WRAPPERCACHE_INTERFACE_MAP_ENTRY + NS_INTERFACE_MAP_ENTRY(nsISupports) + NS_INTERFACE_MAP_END + ``` + +1. If your class doesn't inherit from a class that implements + `GetParentObject`, then add a function of that name that, for a + given instance of your class, returns the same object every time + (unless you write explicit code that handles your parent object + changing by reparenting JS wrappers, as nodes do). The idea is that + walking the `GetParentObject` chain will eventually get you to a + Window, so that every Web IDL object is associated with a particular + Window. + For example, `nsINode::GetParentObject` returns the node's owner + document. The return type of `GetParentObject` doesn't matter other + than it must either singly-inherit from `nsISupports` or have a + corresponding + [`ToSupports`](https://searchfox.org/mozilla-central/search?q=ToSupports&path=&case=true®exp=false) + method that can produce an `nsISupports` from it. (This allows the + return value to be implicitly converted to a + [`ParentObject`](https://searchfox.org/mozilla-central/search?q=ParentObject&path=&case=true®exp=false) + instance by the compiler via one of that class's non-explicit + constructors.) + If many instances of `MyInterface` are expected to be created + quickly, the return value of `GetParentObject` should itself inherit + from `nsWrapperCache` for optimal performance. Returning null from + `GetParentObject` is allowed in situations in which it's OK to + associate the resulting object with a random global object for + security purposes; this is not usually ok for things that are exposed + to web content. Again, if you do not need wrapper caching you don't + need to do this. The actual type returned from `GetParentObject` + must be defined in a header included from your implementation header, + so that this type's definition is visible to the binding code. + +1. Add the Web IDL for `MyInterface` in `dom/webidl` and to the list + in `dom/webidl/moz.build`. + +1. Add an entry to `dom/bindings/Bindings.conf` that sets some basic + information about the implementation of the interface. If the C++ + type is not `mozilla::dom::MyInterface`, you need to set the + `'nativeType'` to the right type. If the type is not in the header + file one gets by replacing '::' with '/' and appending '`.h`', then + add a corresponding `'headerFile'` annotation (or + [`HeaderFile`](#headerfile-path-to-headerfile-h) annotation to the .webidl file). If + you don't have to set any annotations, then you don't need to add an + entry either and the code generator will simply assume the defaults + here. Note that using a `'headerFile'` annotation is generally not + recommended. If you do use it, you will need to make sure your + header includes all the headers needed for your [`Func`](#func-funcname) + annotations. + +1. Add external interface entries to `Bindings.conf` for whatever + non-Web IDL interfaces your new interface has as arguments or return + values. + +1. Implement a `WrapObject` override on `mozilla::dom::MyInterface` + that just calls through to + `mozilla::dom::MyInterface_Binding::Wrap`. Note that if your C++ + type is implementing multiple distinct Web IDL interfaces, you need + to choose which `mozilla::dom::MyInterface_Binding::Wrap` to call + here. See `AudioContext::WrapObject`, for example. + +1. Expose whatever methods the interface needs on + `mozilla::dom::MyInterface`. These can be inline, virtual, have any + calling convention, and so forth, as long as they have the right + argument types and return types. You can see an example of what the + function declarations should look like by running + `mach webidl-example MyInterface`. This will produce two files in + `dom/bindings` in your objdir: `MyInterface-example.h` and + `MyInterface-example.cpp`, which show a basic implementation of the + interface using a class that inherits from `nsISupports` and has a + wrapper cache. + +See this [sample patch that migrates window.performance.\* to Web IDL +bindings](https://hg.mozilla.org/mozilla-central/rev/dd08c10193c6). + +<div class="note"><div class="admonition-title">Note</div> + +If your object can only be reflected into JS by creating it, not by +retrieving it from somewhere, you can skip steps 1 and 2 above and +instead add `'wrapperCache': False` to your descriptor. You will +need to flag the functions that return your object as +[`[NewObject]`](https://webidl.spec.whatwg.org/#NewObject) in +the Web IDL. If your object is not refcounted then the return value of +functions that return it should return a UniquePtr. + +</div> + +## C++ reflections of Web IDL constructs + +### C++ reflections of Web IDL operations (methods) + +A Web IDL operation is turned into a method call on the underlying C++ +object. The return type and argument types are determined [as described +below](#c-reflections-of-webidl-constructs). In addition to those, all [methods that are +allowed to throw](#throws-getterthrows-setterthrows) will get an `ErrorResult&` argument +appended to their argument list. Non-static methods that use certain +Web IDL types like `any` or `object` will get a `JSContext*` +argument prepended to the argument list. Static methods will be passed a +[`const GlobalObject&`](#globalobject) for the relevant global and +can get a `JSContext*` by calling `Context()` on it. + +The name of the C++ method is simply the name of the Web IDL operation +with the first letter converted to uppercase. + +Web IDL overloads are turned into C++ overloads: they simply call C++ +methods with the same name and different signatures. + +For example, this Web IDL: + +``` webidl +interface MyInterface +{ + undefined doSomething(long number); + double doSomething(MyInterface? otherInstance); + + [Throws] + MyInterface doSomethingElse(optional long maybeNumber); + [Throws] + undefined doSomethingElse(MyInterface otherInstance); + + undefined doTheOther(any something); + + undefined doYetAnotherThing(optional boolean actuallyDoIt = false); + + static undefined staticOperation(any arg); +}; +``` + +will require these method declarations: + +``` cpp +class MyClass +{ + void DoSomething(int32_t a number); + double DoSomething(MyClass* aOtherInstance); + + already_AddRefed<MyInterface> DoSomethingElse(Optional<int32_t> aMaybeNumber, + ErrorResult& rv); + void DoSomethingElse(MyClass& aOtherInstance, ErrorResult& rv); + + void DoTheOther(JSContext* cx, JS::Value aSomething); + + void DoYetAnotherThing(bool aActuallyDoIt); + + static void StaticOperation(const GlobalObject& aGlobal, JS::Value aSomething); +} +``` + +### C++ reflections of Web IDL attributes + +A Web IDL attribute is turned into a pair of method calls for the getter +and setter on the underlying C++ object. A readonly attribute only has a +getter and no setter. + +The getter's name is the name of the attribute with the first letter +converted to uppercase. This has `Get` prepended to it if any of these +conditions hold: + +1. The type of the attribute is nullable. +1. The getter can throw. +1. The return value of the attribute is returned via an out parameter in + the C++. + +The method signature for the getter looks just like an operation with no +arguments and the attribute's type as the return type. + +The setter's name is `Set` followed by the name of the attribute with +the first letter converted to uppercase. The method signature looks just +like an operation with an undefined return value and a single argument +whose type is the attribute's type. + +### C++ reflections of Web IDL constructors + +A Web IDL constructor is turned into a static class method named +`Constructor`. The arguments of this method will be the arguments of +the Web IDL constructor, with a +[`const GlobalObject&`](#globalobject) for the relevant global +prepended. For the non-worker case, the global is typically the inner +window for the DOM Window the constructor function is attached to. If a +`JSContext*` is also needed due to some of the argument types, it will +come after the global. The return value of the constructor for +`MyInterface` is exactly the same as that of a method returning an +instance of `MyInterface`. Constructors are always allowed to throw. + +For example, this IDL: + +``` webidl +interface MyInterface { + constructor(); + constructor(unsigned long someNumber); +}; +``` + +will require the following declarations in `MyClass`: + +``` cpp +class MyClass { + // Various nsISupports stuff or whatnot + static + already_AddRefed<MyClass> Constructor(const GlobalObject& aGlobal, + ErrorResult& rv); + static + already_AddRefed<MyClass> Constructor(const GlobalObject& aGlobal, + uint32_t aSomeNumber, + ErrorResult& rv); +}; +``` + +### C++ reflections of Web IDL types + +The exact C++ representation for Web IDL types can depend on the precise +way that they're being used (e.g., return values, arguments, and +sequence or dictionary members might all have different +representations). + +Unless stated otherwise, a type only has one representation. Also, +unless stated otherwise, nullable types are represented by wrapping +[`Nullable<>`](#nullable-t) around the base type. + +In all cases, optional arguments which do not have a default value are +represented by wrapping [`const Optional<>&`](#optional-t) around the +representation of the argument type. If the argument type is a C++ +reference, it will also become a [`NonNull<>`](#nonnull-t) around the +actual type of the object in the process. Optional arguments which do +have a default value are just represented by the argument type itself, +set to the default value if the argument was not in fact passed in. + +Variadic Web IDL arguments are treated as a +[`const Sequence<>&`](#sequence-t) around the actual argument type. + +Here's a table, see the specific sections below for more details and +explanations. + +| Web IDL Type | Argument Type | Return Type | Dictionary/Member Type | +| -------------------------- | --------------------------------- | ---------------------------------------------------------------------------------------------------------------- | -------------------------------------- | +| any | `JS::Handle<JS::Value>` | `JS::MutableHandle<JS::Value>` | `JS::Value` | +| boolean | `bool` | `bool` | `bool` | +| byte | `int8_t` | `int8_t` | `int8_t` | +| ByteString | `const nsACString&` | `nsCString&` _(outparam)_<br>`nsACString&` _(outparam)_ | `nsCString` | +| Date | | | `mozilla::dom::Date` | +| DOMString | `const nsAString&` | [`mozilla::dom::DOMString&`](#domstring-c) _(outparam)_<br>`nsAString&` _(outparam)_<br>`nsString&` _(outparam)_ | `nsString` | +| UTF8String | `const nsACString&` _(outparam)_ | `nsACString&` | `nsCString` | +| double | `double` | `double` | `double` | +| float | `float` | `float` | `float` | +| interface:<br>non-nullable | `Foo&` | `already_addRefed<Foo>` | [`OwningNonNull<Foo>`](#owningnonnull-t) | +| interface:<br>nullable | `Foo*` | `already_addRefed<Foo>`<br>`Foo*` | `RefPtr<Foo>` | +| long | `int32_t` | `int32_t` | `int32_t` | +| long long | `int64_t` | `int64_t` | `int64_t` | +| object | `JS::Handle<JSObject*>` | `JS::MutableHandle<JSObject*>` | `JSObject*` | +| octet | `uint8_t` | `uint8_t` | `uint8_t` | +| sequence | [`const Sequence<T>&`](#sequence-t) | `nsTArray<T>&` _(outparam)_ | | +| short | `int16_t` | `int16_t` | `int16_t` | +| unrestricted double | `double` | `double` | `double` | +| unrestricted float | `float` | `float` | `float` | +| unsigned long | `uint32_t` | `uint32_t` | `uint32_t` | +| unsigned long long | `uint64_t` | `uint64_t` | `uint64_t` | +| unsigned short | `uint16_t` | `uint16_t` | `uint16_t` | +| USVString | `const nsAString&` | [`mozilla::dom::DOMString&`](#domstring-c) _(outparam)_<br>`nsAString&` _(outparam)_<br>`nsString&` _(outparam)_ | `nsString` | + +#### `any` + +`any` is represented in three different ways, depending on use: + +- `any` arguments become `JS::Handle<JS::Value>`. They will be in + the compartment of the passed-in JSContext. +- `any` return values become a `JS::MutableHandle<JS::Value>` out + param appended to the argument list. This comes after all IDL + arguments, but before the `ErrorResult&`, if any, for the method. + The return value is allowed to be in any compartment; bindings will + wrap it into the context compartment as needed. +- `any` dictionary members and sequence elements become + `JS::Value`. The dictionary members and sequence elements are + guaranteed to be marked by whomever puts the sequence or dictionary + on the stack, using `SequenceRooter` and `DictionaryRooter`. + +Methods using `any` always get a `JSContext*` argument. + +For example, this Web IDL: + +``` webidl +interface Test { + attribute any myAttr; + any myMethod(any arg1, sequence<any> arg2, optional any arg3); +}; +``` + +will correspond to these C++ function declarations: + +``` cpp +void MyAttr(JSContext* cx, JS::MutableHandle<JS::Value> retval); +void SetMyAttr(JSContext* cx, JS::Handle<JS::Value> value); +void MyMethod(JSContext* cx, JS::Handle<JS::Value> arg1, + const Sequence<JS::Value>& arg2, + const Optional<JS::Handle<JS::Value>>& arg3, + JS::MutableHandle<JS::Value> retval); +``` + +#### `boolean` + +The `boolean` Web IDL type is represented as a C++ `bool`. + +For example, this Web IDL: + +``` webidl +interface Test { + attribute boolean myAttr; + boolean myMethod(optional boolean arg); +}; +``` + +will correspond to these C++ function declarations: + +``` cpp +bool MyAttr(); +void SetMyAttr(bool value); +JS::Value MyMethod(const Optional<bool>& arg); +``` + +#### Integer types + +Integer Web IDL types are mapped to the corresponding C99 stdint types. + +For example, this Web IDL: + +``` webidl +interface Test { + attribute short myAttr; + long long myMethod(unsigned long? arg); +}; +``` + +will correspond to these C++ function declarations: + +``` cpp +int16_t MyAttr(); +void SetMyAttr(int16_t value); +int64_t MyMethod(const Nullable<uint32_t>& arg); +``` + +#### Floating point types + +Floating point Web IDL types are mapped to the C++ type of the same +name. So `float` and `unrestricted float` become a C++ `float`, +while `double` and `unrestricted double` become a C++ `double`. + +For example, this Web IDL: + +``` webidl +interface Test { + float myAttr; + double myMethod(unrestricted double? arg); +}; +``` + +will correspond to these C++ function declarations: + +``` cpp +float MyAttr(); +void SetMyAttr(float value); +double MyMethod(const Nullable<double>& arg); +``` + +#### `DOMString` + +Strings are reflected in three different ways, depending on use: + +- String arguments become `const nsAString&`. +- String return values become a + [`mozilla::dom::DOMString&`](#domstring-c) out param + appended to the argument list. This comes after all IDL arguments, + but before the `ErrorResult&`, if any, for the method. Note that + this allows callees to declare their methods as taking an + `nsAString&` or `nsString&` if desired. +- Strings in sequences, dictionaries, owning unions, and variadic + arguments become `nsString`. + +Nullable strings are represented by the same types as non-nullable ones, +but the string will return true for `DOMStringIsNull()`. Returning +null as a string value can be done using `SetDOMStringToNull` on the +out param if it's an `nsAString` or calling `SetNull()` on a +`DOMString`. + +For example, this Web IDL: + +``` webidl +interface Test { + DOMString myAttr; + [Throws] + DOMString myMethod(sequence<DOMString> arg1, DOMString? arg2, optional DOMString arg3); +}; +``` + +will correspond to these C++ function declarations: + +``` cpp +void GetMyAttr(nsString& retval); +void SetMyAttr(const nsAString& value); +void MyMethod(const Sequence<nsString>& arg1, const nsAString& arg2, + const Optional<nsAString>& arg3, nsString& retval, ErrorResult& rv); +``` + +#### `USVString` + +`USVString` is reflected just like `DOMString`. + +#### `UTF8String` + +`UTF8String` is a string with guaranteed-valid UTF-8 contents. It is +not a standard in the Web IDL spec, but its observables are the same as +those of `USVString`. + +It is a good fit for when the specification allows a `USVString`, but +you want to process the string as UTF-8 rather than UTF-16. + +It is reflected in three different ways, depending on use: + +- Arguments become `const nsACString&`. +- Return values become an `nsACString&` out param appended to the + argument list. This comes after all IDL arguments, but before the + `ErrorResult&`, if any, for the method. +- In sequences, dictionaries owning unions, and variadic arguments it + becomes `nsCString`. + +Nullable `UTF8String`s are represented by the same types as +non-nullable ones, but the string will return true for `IsVoid()`. +Returning null as a string value can be done using `SetIsVoid()` on +the out param. + +#### `ByteString` + +`ByteString` is reflected in three different ways, depending on use: + +- `ByteString` arguments become `const nsACString&`. +- `ByteString` return values become an `nsCString&` out param + appended to the argument list. This comes after all IDL arguments, + but before the `ErrorResult&`, if any, for the method. +- `ByteString` in sequences, dictionaries, owning unions, and + variadic arguments becomes `nsCString`. + +Nullable `ByteString` are represented by the same types as +non-nullable ones, but the string will return true for `IsVoid()`. +Returning null as a string value can be done using `SetIsVoid()` on +the out param. + +#### `object` + +`object` is represented in three different ways, depending on use: + +- `object` arguments become `JS::Handle<JSObject*>`. They will be + in the compartment of the passed-in JSContext. +- `object` return values become a `JS::MutableHandle<JSObject*>` + out param appended to the argument list. This comes after all IDL + arguments, but before the `ErrorResult&`, if any, for the method. + The return value is allowed to be in any compartment; bindings will + wrap it into the context compartment as needed. +- `object` dictionary members and sequence elements become + `JSObject*`. The dictionary members and sequence elements are + guaranteed to be marked by whoever puts the sequence or dictionary on + the stack, using `SequenceRooter` and `DictionaryRooter`. + +Methods using `object` always get a `JSContext*` argument. + +For example, this Web IDL: + +``` webidl +interface Test { + object myAttr; + object myMethod(object arg1, object? arg2, sequence<object> arg3, optional object arg4, + optional object? arg5); +}; +``` + +will correspond to these C++ function declarations: + +``` cpp +void GetMyAttr(JSContext* cx, JS::MutableHandle<JSObject*> retval); +void SetMyAttr(JSContext* cx, JS::Handle<JSObject*> value); +void MyMethod(JSContext* cx, JS::Handle<JSObject*> arg1, JS::Handle<JSObject*> arg2, + const Sequence<JSObject*>& arg3, + const Optional<JS::Handle<JSObject*>>& arg4, + const Optional<JS::Handle<JSObject*>>& arg5, + JS::MutableHandle<JSObject*> retval); +``` + +#### Interface types + +There are four kinds of interface types in the Web IDL bindings. Callback +interfaces are used to represent script objects that browser code can +call into. External interfaces are used to represent objects that have +not been converted to the Web IDL bindings yet. Web IDL interfaces are +used to represent Web IDL binding objects. "SpiderMonkey" interfaces are +used to represent objects that are implemented natively by the +JavaScript engine (e.g., typed arrays). + +##### Callback interfaces + +Callback interfaces are represented in C++ as objects inheriting from +[`mozilla::dom::CallbackInterface`](#callbackinterface), whose +name, in the `mozilla::dom` namespace, matches the name of the +callback interface in the Web IDL. The exact representation depends on +how the type is being used. + +- Nullable arguments become `Foo*`. +- Non-nullable arguments become `Foo&`. +- Return values become `already_AddRefed<Foo>` or `Foo*` as + desired. The pointer form is preferred because it results in faster + code, but it should only be used if the return value was not addrefed + (and so it can only be used if the return value is kept alive by the + callee until at least the binding method has returned). +- Web IDL callback interfaces in sequences, dictionaries, owning unions, + and variadic arguments are represented by `RefPtr<Foo>` if nullable + and [`OwningNonNull<Foo>`](#owningnonnull-t) otherwise. + +If the interface is a single-operation interface, the object exposes two +methods that both invoke the same underlying JS callable. The first of +these methods allows the caller to pass in a `this` object, while the +second defaults to `undefined` as the `this` value. In either case, +the `this` value is only used if the callback interface is implemented +by a JS callable. If it's implemented by an object with a property whose +name matches the operation, the object itself is always used as +`this`. + +If the interface is not a single-operation interface, it just exposes a +single method for every IDL method/getter/setter. + +The signatures of the methods correspond to the signatures for throwing +IDL methods/getters/setters with an additional trailing +`mozilla::dom::CallbackObject::ExceptionHandling aExceptionHandling` +argument, defaulting to `eReportExceptions`. +If `aReportExceptions` is set to `eReportExceptions`, the methods +will report JS exceptions before returning. If `aReportExceptions` is +set to `eRethrowExceptions`, JS exceptions will be stashed in the +`ErrorResult` and will be reported when the stack unwinds to wherever +the `ErrorResult` was set up. + +For example, this Web IDL: + +``` webidl +callback interface MyCallback { + attribute long someNumber; + short someMethod(DOMString someString); +}; +callback interface MyOtherCallback { + // single-operation interface + short doSomething(Node someNode); +}; +interface MyInterface { + attribute MyCallback foo; + attribute MyCallback? bar; +}; +``` + +will lead to these C++ class declarations in the `mozilla::dom` +namespace: + +``` cpp +class MyCallback : public CallbackInterface +{ + int32_t GetSomeNumber(ErrorResult& rv, ExceptionHandling aExceptionHandling = eReportExceptions); + void SetSomeNumber(int32_t arg, ErrorResult& rv, + ExceptionHandling aExceptionHandling = eReportExceptions); + int16_t SomeMethod(const nsAString& someString, ErrorResult& rv, + ExceptionHandling aExceptionHandling = eReportExceptions); +}; + +class MyOtherCallback : public CallbackInterface +{ +public: + int16_t + DoSomething(nsINode& someNode, ErrorResult& rv, + ExceptionHandling aExceptionHandling = eReportExceptions); + + template<typename T> + int16_t + DoSomething(const T& thisObj, nsINode& someNode, ErrorResult& rv, + ExceptionHandling aExceptionHandling = eReportExceptions); +}; +``` + +and these C++ function declarations on the implementation of +`MyInterface`: + +``` cpp +already_AddRefed<MyCallback> GetFoo(); +void SetFoo(MyCallback&); +already_AddRefed<MyCallback> GetBar(); +void SetBar(MyCallback*); +``` + +A consumer of MyCallback would be able to use it like this: + +``` cpp +void +SomeClass::DoSomethingWithCallback(MyCallback& aCallback) +{ + ErrorResult rv; + int32_t number = aCallback.GetSomeNumber(rv); + if (rv.Failed()) { + // The error has already been reported to the JS console; you can handle + // things however you want here. + return; + } + + // For some reason we want to catch and rethrow exceptions from SetSomeNumber, say. + aCallback.SetSomeNumber(2*number, rv, eRethrowExceptions); + if (rv.Failed()) { + // The exception is now stored on rv. This code MUST report + // it usefully; otherwise it will assert. + } +} +``` + +##### External interfaces + +External interfaces are represented in C++ as objects that XPConnect +knows how to unwrap to. This can mean XPCOM interfaces (whether declared +in XPIDL or not) or it can mean some type that there's a castable native +unwrapping function for. The C++ type to be used should be the +`nativeType` listed for the external interface in the +[`Bindings.conf`](#bindings-conf-details) file. The exact representation +depends on how the type is being used. + +- Arguments become `nsIFoo*`. +- Return values can be `already_AddRefed<nsIFoo>` or `nsIFoo*` as + desired. The pointer form is preferred because it results in faster + code, but it should only be used if the return value was not addrefed + (and so it can only be used if the return value is kept alive by the + callee until at least the binding method has returned). +- External interfaces in sequences, dictionaries, owning unions, and + variadic arguments are represented by `RefPtr<nsIFoo>`. + +##### Web IDL interfaces + +Web IDL interfaces are represented in C++ as C++ classes. The class +involved must either be refcounted or must be explicitly annotated in +`Bindings.conf` as being directly owned by the JS object. If the class +inherits from `nsISupports`, then the canonical `nsISupports` must +be on the primary inheritance chain of the object. If the interface has +a parent interface, the C++ class corresponding to the parent must be on +the primary inheritance chain of the object. This guarantees that a +`void*` can be stored in the JSObject which can then be +`reinterpret_cast` to any of the classes that correspond to interfaces +the object implements. The C++ type to be used should be the +`nativeType` listed for the interface in the +[`Bindings.conf`](#bindings-conf-details) file, or +`mozilla::dom::InterfaceName` if none is listed. The exact +representation depends on how the type is being used. + +- Nullable arguments become `Foo*`. +- Non-nullable arguments become `Foo&`. +- Return values become `already_AddRefed<Foo>` or `Foo*` as + desired. The pointer form is preferred because it results in faster + code, but it should only be used if the return value was not addrefed + (and so it can only be used if the return value is kept alive by the + callee until at least the binding method has returned). +- Web IDL interfaces in sequences, dictionaries, owning unions, and + variadic arguments are represented by `RefPtr<Foo>` if nullable and + [`OwningNonNull<Foo>`](#owningnonnull-t) otherwise. + +For example, this Web IDL: + +``` webidl +interface MyInterface { + attribute MyInterface myAttr; + undefined passNullable(MyInterface? arg); + MyInterface? doSomething(sequence<MyInterface> arg); + MyInterface doTheOther(sequence<MyInterface?> arg); + readonly attribute MyInterface? nullableAttr; + readonly attribute MyInterface someOtherAttr; + readonly attribute MyInterface someYetOtherAttr; +}; +``` + +Would correspond to these C++ function declarations: + +``` cpp +already_AddRefed<MyClass> MyAttr(); +void SetMyAttr(MyClass& value); +void PassNullable(MyClass* arg); +already_AddRefed<MyClass> doSomething(const Sequence<OwningNonNull<MyClass>>& arg); +already_AddRefed<MyClass> doTheOther(const Sequence<RefPtr<MyClass>>& arg); +already_Addrefed<MyClass> GetNullableAttr(); +MyClass* SomeOtherAttr(); +MyClass* SomeYetOtherAttr(); // Don't have to return already_AddRefed! +``` + +##### "SpiderMonkey" interfaces + +Typed array, array buffer, and array buffer view arguments are +represented by the objects in [`TypedArray.h`](#typed-arrays-arraybuffers-array-buffer-views). For +example, this Web IDL: + +``` webidl +interface Test { + undefined passTypedArrayBuffer(ArrayBuffer arg); + undefined passTypedArray(ArrayBufferView arg); + undefined passInt16Array(Int16Array? arg); +} +``` + +will correspond to these C++ function declarations: + +``` cpp +void PassTypedArrayBuffer(const ArrayBuffer& arg); +void PassTypedArray(const ArrayBufferView& arg); +void PassInt16Array(const Nullable<Int16Array>& arg); +``` + +Typed array return values become a `JS::MutableHandle<JSObject*>` out +param appended to the argument list. This comes after all IDL arguments, +but before the `ErrorResult&`, if any, for the method. The return +value is allowed to be in any compartment; bindings will wrap it into +the context compartment as needed. + +Typed arrays store a `JSObject*` and hence need to be rooted +properly. On-stack typed arrays can be declared as +`RootedTypedArray<TypedArrayType>` (e.g. +`RootedTypedArray<Int16Array>`). Typed arrays on the heap need to be +traced. + +#### Dictionary types + +A dictionary argument is represented by a const reference to a struct +whose name is the dictionary name in the `mozilla::dom` namespace. +The struct has one member for each of the dictionary's members with the +same name except the first letter uppercased and prefixed with "m". The +members that are required or have default values have types as described +under the corresponding Web IDL type in this document. The members that +are not required and don't have default values have those types wrapped +in [`Optional<>`](#optional-t). + +Dictionary return values are represented by an out parameter whose type +is a non-const reference to the struct described above, with all the +members that have default values preinitialized to those default values. + +Note that optional dictionary arguments are always forced to have a +default value of an empty dictionary by the IDL parser and code +generator, so dictionary arguments are never wrapped in `Optional<>`. + +If necessary, dictionaries can be directly initialized from a +`JS::Value` in C++ code by invoking their `Init()` method. Consumers +doing this should declare their dictionary as +`RootedDictionary<DictionaryName>`. When this is done, passing in a +null `JSContext*` is allowed if the passed-in `JS::Value` is +`JS::NullValue()`. Likewise, a dictionary struct can be converted to a +`JS::Value` in C++ by calling `ToJSValue` with the dictionary as the +second argument. If `Init()` or `ToJSValue()` returns false, they +will generally set a pending exception on the JSContext; reporting those +is the responsibility of the caller. + +For example, this Web IDL: + +``` webidl +dictionary Dict { + long foo = 5; + DOMString bar; +}; + +interface Test { + undefined initSomething(optional Dict arg = {}); +}; +``` + +will correspond to this C++ function declaration: + +``` cpp +void InitSomething(const Dict& arg); +``` + +and the `Dict` struct will look like this: + +``` cpp +struct Dict { + bool Init(JSContext* aCx, JS::Handle<JS::Value> aVal, const char* aSourceDescription = "value"); + + Optional<nsString> mBar; + int32_t mFoo; +} +``` + +Note that the dictionary members are sorted in the struct in +alphabetical order. + +##### API for working with dictionaries + +There are a few useful methods found on dictionaries and dictionary +members that you can use to quickly determine useful things. + +- **member.WasPassed()** - as the name suggests, was a particular + member passed? + (e.g., `if (arg.foo.WasPassed() { /* do nice things!*/ }`) +- **dictionary.IsAnyMemberPresent()** - great for checking if you need + to do anything. + (e.g., `if (!arg.IsAnyMemberPresent()) return; // nothing to do`) +- **member.Value()** - getting the actual data/value of a member that + was passed. + (e.g., `mBar.Assign(args.mBar.value())`) + +Example implementation using all of the above: + +``` cpp +void +MyInterface::InitSomething(const Dict& aArg){ + if (!aArg.IsAnyMemberPresent()) { + return; // nothing to do! + } + if (aArg.mBar.WasPassed() && !mBar.Equals(aArg.mBar.value())) { + mBar.Assign(aArg.mBar.Value()); + } +} +``` + +#### Enumeration types + +Web IDL enumeration types are represented as C++ enum classes. The values +of the C++ enum are named by taking the strings in the Web IDL +enumeration, replacing all non-alphanumerics with underscores, and +uppercasing the first letter, with a special case for the empty string, +which becomes the value `_empty`. + +For a Web IDL enum named `MyEnum`, the C++ enum is named `MyEnum` and +placed in the `mozilla::dom` namespace, while the values are placed in +the `mozilla::dom::MyEnum` namespace. There is also a +`mozilla::dom::MyEnumValues::strings` which is an array of +`mozilla::dom::EnumEntry` structs that gives access to the string +representations of the values. + +The type of the enum class is automatically selected to be the smallest +unsigned integer type that can hold all the values. In practice, this +is always uint8_t, because Web IDL enums tend to not have more than 255 +values. + +For example, this Web IDL: + +``` webidl +enum MyEnum { + "something", + "something-else", + "", + "another" +}; +``` + +would lead to this C++ enum declaration: + +``` cpp +enum class MyEnum : uint8_t { + Something, + Something_else, + _empty, + Another +}; + +namespace MyEnumValues { +extern const EnumEntry strings[10]; +} // namespace MyEnumValues +``` + +#### Callback function types + +Callback functions are represented as an object, inheriting from +[`mozilla::dom::CallbackFunction`](#callbackfunction), whose name, +in the `mozilla::dom` namespace, matches the name of the callback +function in the Web IDL. If the type is nullable, a pointer is passed in; +otherwise a reference is passed in. + +The object exposes two `Call` methods, which both invoke the +underlying JS callable. The first `Call` method has the same signature +as a throwing method declared just like the callback function, with an +additional trailing `mozilla::dom::CallbackObject::ExceptionHandling aExceptionHandling` +argument, defaulting to `eReportExceptions`, +and calling it will invoke the callable with `undefined` as the +`this` value. The second `Call` method allows passing in an explicit +`this` value as the first argument. This second call method is a +template on the type of the first argument, so the `this` value can be +passed in in whatever form is most convenient, as long as it's either a +type that can be wrapped by XPConnect or a Web IDL interface type. + +If `aReportExceptions` is set to `eReportExceptions`, the `Call` +methods will report JS exceptions before returning. If +`aReportExceptions` is set to `eRethrowExceptions`, JS exceptions +will be stashed in the `ErrorResult` and will be reported when the +stack unwinds to wherever the `ErrorResult` was set up. + +For example, this Web IDL: + +``` webidl +callback MyCallback = long (MyInterface arg1, boolean arg2); +interface MyInterface { + attribute MyCallback foo; + attribute MyCallback? bar; +}; +``` + +will lead to this C++ class declaration, in the `mozilla::dom` +namespace: + +``` cpp +class MyCallback : public CallbackFunction +{ +public: + int32_t + Call(MyInterface& arg1, bool arg2, ErrorResult& rv, + ExceptionHandling aExceptionHandling = eReportExceptions); + + template<typename T> + int32_t + Call(const T& thisObj, MyInterface& arg1, bool arg2, ErrorResult& rv, + ExceptionHandling aExceptionHandling = eReportExceptions); +}; +``` + +and these C++ function declarations in the `MyInterface` class: + +``` cpp +already_AddRefed<MyCallback> GetFoo(); +void SetFoo(MyCallback&); +already_AddRefed<MyCallback> GetBar(); +void SetBar(MyCallback*); +``` + +A consumer of MyCallback would be able to use it like this: + +``` cpp +void +SomeClass::DoSomethingWithCallback(MyCallback& aCallback, MyInterface& aInterfaceInstance) +{ + ErrorResult rv; + int32_t number = aCallback.Call(aInterfaceInstance, false, rv); + if (rv.Failed()) { + // The error has already been reported to the JS console; you can handle + // things however you want here. + return; + } + + // Now for some reason we want to catch and rethrow exceptions from the callback, + // and use "this" as the this value for the call to JS. + number = aCallback.Call(*this, true, rv, eRethrowExceptions); + if (rv.Failed()) { + // The exception is now stored on rv. This code MUST report + // it usefully; otherwise it will assert. + } +} +``` + +#### Sequences + +Sequence arguments are represented by +[`const Sequence<T>&`](#sequence-t), where `T` depends on the type +of elements in the Web IDL sequence. + +Sequence return values are represented by an `nsTArray<T>` out param +appended to the argument list, where `T` is the return type for the +elements of the Web IDL sequence. This comes after all IDL arguments, but +before the `ErrorResult&`, if any, for the method. + +#### Arrays + +IDL array objects are not supported yet. The spec on these is likely to +change drastically anyway. + +#### Union types + +Union types are reflected as a struct in the `mozilla::dom` namespace. +There are two kinds of union structs: one kind does not keep its members +alive (is "non-owning"), and the other does (is "owning"). Const +references to non-owning unions are used for plain arguments. Owning +unions are used in dictionaries, sequences, and for variadic arguments. +Union return values become a non-const owning union out param. The name +of the struct is the concatenation of the names of the types in the +union, with "Or" inserted between them, and for an owning struct +"Owning" prepended. So for example, this IDL: + +``` webidl +undefined passUnion((object or long) arg); +(object or long) receiveUnion(); +undefined passSequenceOfUnions(sequence<(object or long)> arg); +undefined passOtherUnion((HTMLDivElement or ArrayBuffer or EventInit) arg); +``` + +would correspond to these C++ function declarations: + +``` cpp +void PassUnion(const ObjectOrLong& aArg); +void ReceiveUnion(OwningObjectObjectOrLong& aArg); +void PassSequenceOfUnions(const Sequence<OwningObjectOrLong>& aArg); +void PassOtherUnion(const HTMLDivElementOrArrayBufferOrEventInit& aArg); +``` + +Union structs expose accessors to test whether they're of a given type +and to get hold of the data of that type. They also expose setters that +set the union as being of a particular type and return a reference to +the union's internal storage where that type could be stored. The one +exception is the `object` type, which uses a somewhat different form +of setter where the `JSObject*` is passed in directly. For example, +`ObjectOrLong` would have the following methods: + +``` cpp +bool IsObject() const; +JSObject* GetAsObject() const; +void SetToObject(JSContext*, JSObject*); +bool IsLong() const; +int32_t GetAsLong() const; +int32_t& SetAsLong() +``` + +Owning unions used on the stack should be declared as a +`RootedUnion<UnionType>`, for example, +`RootedUnion<OwningObjectOrLong>`. + +#### `Date` + +Web IDL `Date` types are represented by a `mozilla::dom::Date` +struct. + +### C++ reflections of Web IDL declarations + +Web IDL declarations (maplike/setlike/iterable) are turned into a set of +properties and functions on the interface they are declared on. Each has +a different set of helper functions it comes with. In addition, for +iterable, there are requirements for C++ function implementation by the +interface developer. + +#### Maplike + +Example Interface: + +``` webidl +interface StringToLongMap { + maplike<DOMString, long>; +}; +``` + +The bindings for this interface will generate the storage structure for +the map, as well as helper functions for accessing that structure from +C++. The generated C++ API will look as follows: + +``` cpp +namespace StringToLongMapBinding { +namespace MaplikeHelpers { +void Clear(mozilla::dom::StringToLongMap* self, ErrorResult& aRv); +bool Delete(mozilla::dom::StringToLongMap* self, const nsAString& aKey, ErrorResult& aRv); +bool Has(mozilla::dom::StringToLongMap* self, const nsAString& aKey, ErrorResult& aRv); +void Set(mozilla::dom::StringToLongMap* self, const nsAString& aKey, int32_t aValue, ErrorResult& aRv); +} // namespace MaplikeHelpers +} // namespace StringToLongMapBindings +``` + +#### Setlike + +Example Interface: + +``` webidl +interface StringSet { + setlike<DOMString>; +}; +``` + +The bindings for this interface will generate the storage structure for +the set, as well as helper functions for accessing that structure from +c++. The generated C++ API will look as follows: + +``` cpp +namespace StringSetBinding { +namespace SetlikeHelpers { +void Clear(mozilla::dom::StringSet* self, ErrorResult& aRv); +bool Delete(mozilla::dom::StringSet* self, const nsAString& aKey, ErrorResult& aRv); +bool Has(mozilla::dom::StringSet* self, const nsAString& aKey, ErrorResult& aRv); +void Add(mozilla::dom::StringSet* self, const nsAString& aKey, ErrorResult& aRv); +} // namespace SetlikeHelpers +} +``` + +#### Iterable + +Unlike maplike and setlike, iterable does not have any C++ helpers, as +the structure backing the iterable data for the interface is left up to +the developer. With that in mind, the generated iterable bindings expect +the wrapper object to provide certain methods for the interface to +access. + +Iterable interfaces have different requirements, based on if they are +single or pair value iterators. + +Example Interface for a single value iterator: + +``` webidl +interface LongIterable { + iterable<long>; + getter long(unsigned long index); + readonly attribute unsigned long length; +}; +``` + +For single value iterator interfaces, we treat the interface as an +[indexed getter](#indexed-getters), as required by the spec. See the +[indexed getter implementation section](#indexed-getters) for more +information on building this kind of structure. + +Example Interface for a pair value iterator: + +``` webidl +interface StringAndLongIterable { + iterable<DOMString, long>; +}; +``` + +The bindings for this pair value iterator interface require the +following methods be implemented in the C++ object: + +``` cpp +class StringAndLongIterable { +public: + // Returns the number of items in the iterable storage + size_t GetIterableLength(); + // Returns key of pair at aIndex in iterable storage + nsAString& GetKeyAtIndex(uint32_t aIndex); + // Returns value of pair at aIndex in iterable storage + uint32_t& GetValueAtIndex(uint32_t aIndex); +} +``` + +### Stringifiers + +Named stringifiers operations in Web IDL will just invoke the +corresponding C++ method. + +Anonymous stringifiers in Web IDL will invoke the C++ method called +`Stringify`. So, for example, given this IDL: + +``` webidl +interface FirstInterface { + stringifier; +}; + +interface SecondInterface { + stringifier DOMString getStringRepresentation(); +}; +``` + +the corresponding C++ would be: + +``` cpp +class FirstInterface { +public: + void Stringify(nsAString& aResult); +}; + +class SecondInterface { +public: + void GetStringRepresentation(nsAString& aResult); +}; +``` + +### Legacy Callers + +Only anonymous legacy callers are supported, and will invoke the C++ +method called `LegacyCall`. This will be passed the JS "this" value as +the first argument, then the arguments to the actual operation. A +`JSContext` will be passed if any of the operation arguments need it. +So for example, given this IDL: + +``` webidl +interface InterfaceWithCall { + legacycaller long (float arg); +}; +``` + +the corresponding C++ would be: + +``` cpp +class InterfaceWithCall { +public: + int32_t LegacyCall(JS::Handle<JS::Value> aThisVal, float aArgument); +}; +``` + +### Named getters + +If the interface has a named getter, the binding will expect several +methods on the C++ implementation: + +- A `NamedGetter` method. This takes a property name and returns + whatever type the named getter is declared to return. It also has a + boolean out param for whether a property with that name should exist + at all. +- A `NameIsEnumerable` method. This takes a property name and + returns a boolean that indicates whether the property is enumerable. +- A `GetSupportedNames` method. This takes an unsigned integer which + corresponds to the flags passed to the `iterate` proxy trap and + returns a list of property names. For implementations of this method, + the important flags is `JSITER_HIDDEN`. If that flag is set, the + call needs to return all supported property names. If it's not set, + the call needs to return only the enumerable ones. + +The `NameIsEnumerable` and `GetSupportedNames` methods need to agree +on which names are and are not enumerable. The `NamedGetter` and +`GetSupportedNames` methods need to agree on which names are +supported. + +So for example, given this IDL: + +``` webidl +interface InterfaceWithNamedGetter { + getter long(DOMString arg); +}; +``` + +the corresponding C++ would be: + +``` cpp +class InterfaceWithNamedGetter +{ +public: + int32_t NamedGetter(const nsAString& aName, bool& aFound); + bool NameIsEnumerable(const nsAString& aName); + undefined GetSupportedNames(unsigned aFlags, nsTArray<nsString>& aNames); +}; +``` + +### Indexed getters + +If the interface has a indexed getter, the binding will expect the +following methods on the C++ implementation: + +- A `IndexedGetter` method. This takes an integer index value and + returns whatever type the indexed getter is declared to return. It + also has a boolean out param for whether a property with that index + should exist at all. The implementation must set this out param + correctly. The return value is guaranteed to be ignored if the out + param is set to false. + +So for example, given this IDL: + +``` webidl +interface InterfaceWithIndexedGetter { + getter long(unsigned long index); + readonly attribute unsigned long length; +}; +``` + +the corresponding C++ would be: + +``` cpp +class InterfaceWithIndexedGetter +{ +public: + uint32_t Length() const; + int32_t IndexedGetter(uint32_t aIndex, bool& aFound) const; +}; +``` + +## Throwing exceptions from Web IDL methods, getters, and setters + +Web IDL methods, getters, and setters that are [explicitly marked as +allowed to throw](#throws-getterthrows-setterthrows) have an `ErrorResult&` argument as their +last argument. To throw an exception, simply call `Throw()` on the +`ErrorResult&` and return from your C++ back into the binding code. + +In cases when the specification calls for throwing a `TypeError`, you +should use `ErrorResult::ThrowTypeError()` instead of calling +`Throw()`. + +## Custom extended attributes + +Our Web IDL parser and code generator recognize several extended +attributes that are not present in the Web IDL spec. + +### `[Alias=propName]` + +This extended attribute can be specified on a method and indicates that +another property with the specified name will also appear on the +interface prototype object and will have the same Function object value +as the property for the method. For example: + +``` webidl +interface MyInterface { + [Alias=performSomething] undefined doSomething(); +}; +``` + +`MyInterface.prototype.performSomething` will have the same Function +object value as `MyInterface.prototype.doSomething`. + +Multiple `[Alias]` extended attribute can be used on the one method. +`[Alias]` cannot be used on a static method, nor on methods on a +global interface (such as `Window`). + +Aside from regular property names, the name of an alias can be +[Symbol.iterator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/iterator). +This is specified by writing `[Alias="@@iterator"]`. + +### `[BindingAlias=propName]` + +This extended attribute can be specified on an attribute and indicates +that another property with the specified name will also appear on the +interface prototype object and will call the same underlying C++ +implementation for the getter and setter. This is more efficient than +using the same `BinaryName` for both attributes, because it shares the +binding glue code between them. The properties still have separate +getter/setter functions in JavaScript, so from the point of view of web +consumers it's as if you actually had two separate attribute +declarations on your interface. For example: + +``` webidl +interface MyInterface { + [BindingAlias=otherAttr] readonly attribute boolean attr; +}; +``` + +`MyInterface.prototype.otherAttr` and `MyInterface.prototype.attr` +will both exist, have separate getter/setter functions, but call the +same binding glue code and implementation function on the objects +implementing `MyInterface`. + +Multiple `[BindingAlias]` extended attributes can be used on a single +attribute. + +### `[ChromeOnly]` + +This extended attribute can be specified on any method, attribute, or +constant on an interface or on an interface as a whole. It can also be +specified on dictionary members. + +Interface members flagged as `[ChromeOnly]` are only exposed in chrome +Windows (and in particular, are not exposed to webpages). From the point +of view of web content, it's as if the interface member were not there +at all. These members *are* exposed to chrome script working with a +content object via Xrays. + +If specified on an interface as a whole, this functions like +[`[Func]`](#func-funcname) except that the binding code will automatically +check whether the caller script has the system principal (is chrome or a +worker started from a chrome page) instead of calling into the C++ +implementation to determine whether to expose the interface object on +the global. This means that accessing a content global via Xrays will +show `[ChromeOnly]` interface objects on it. + +If specified on a dictionary member, then the dictionary member will +only appear to exist in system-privileged code. + +This extended attribute can be specified together with `[Func]`, and +`[Pref]`. If more than one of these is specified, all conditions will +need to test true for the interface or interface member to be exposed. + +### `[Pref=prefname]` + +This extended attribute can be specified on any method, attribute, or +constant on an interface or on an interface as a whole. It can also be +specified on dictionary members. It takes a value, which must be the +name of a boolean preference exposed from `StaticPrefs`. The +`StaticPrefs` function that will be called is calculated from the +value of the extended attribute, with dots replaced by underscores +(`StaticPrefs::my_pref_name()` in the example below). + +If specified on an interface member, the interface member involved is +only exposed if the preference is set to `true`. An example of how +this can be used: + +``` webidl +interface MyInterface { + attribute long alwaysHere; + [Pref="my.pref.name"] attribute long onlyHereIfEnabled; +}; +``` + +If specified on an interface as a whole, this functions like +[`[Func]`](#func-funcname) except that the binding will check the value of +the preference directly without calling into the C++ implementation of +the interface at all. This is useful when the enable check is simple and +it's desirable to keep the prefname with the Web IDL declaration. + +If specified on a dictionary member, the web-observable behavior when +the pref is set to false will be as if the dictionary did not have a +member of that name defined. That means that on the JS side no +observable get of the property will happen. On the C++ side, the +behavior would be as if the passed-in object did not have a property +with the relevant name: the dictionary member would either be +`!Passed()` or have the default value if there is a default value. + +> An example of how this can be used: + +``` webidl +[Pref="my.pref.name"] +interface MyConditionalInterface { +}; +``` + +This extended attribute can be specified together with `[ChromeOnly]`, +and `[Func]`. If more than one of these is specified, all conditions +will need to test true for the interface or interface member to be +exposed. + +### `[Func="funcname"]` + +This extended attribute can be specified on any method, attribute, or +constant on an interface or on an interface as a whole. It can also be +specified on dictionary members. It takes a value, which must be the +name of a static function. + +If specified on an interface member, the interface member involved is +only exposed if the specified function returns `true`. An example of +how this can be used: + +``` webidl +interface MyInterface { + attribute long alwaysHere; + [Func="MyClass::StuffEnabled"] attribute long onlyHereIfEnabled; +}; +``` + +The function is invoked with two arguments: the `JSContext` that the +operation is happening on and the `JSObject` for the global of the +object that the property will be defined on if the function returns +true. In particular, in the Xray case the `JSContext` is in the caller +compartment (typically chrome) but the `JSObject` is in the target +compartment (typically content). This allows the method implementation +to select which compartment it cares about in its checks. + +The above IDL would also require the following C++: + +``` cpp +class MyClass { + static bool StuffEnabled(JSContext* cx, JSObject* obj); +}; +``` + +If specified on an interface as a whole, then lookups for the interface +object for this interface on a DOM Window will only find it if the +specified function returns true. For objects that can only be created +via a constructor, this allows disabling the functionality altogether +and making it look like the feature is not implemented at all. + +If specified on a dictionary member, the web-observable behavior when +the function returns false will be as if the dictionary did not have a +member of that name defined. That means that on the JS side no +observable get of the property will happen. On the C++ side, the +behavior would be as if the passed-in object did not have a property +with the relevant name: the dictionary member would either be +`!Passed()` or have the default value if there is a default value. + +An example of how `[Func]` can be used: + +``` webidl +[Func="MyClass::MyConditionalInterfaceEnabled"] +interface MyConditionalInterface { +}; +``` + +In this case, the C++ function is passed a `JS::Handle<JSObject*>`. So +the C++ in this case would look like this: + +``` cpp +class MyClass { + static bool MyConditionalInterfaceEnabled(JSContext* cx, JS::Handle<JSObject*> obj); +}; +``` + +Just like in the interface member case, the `JSContext` is in the +caller compartment but the `JSObject` is the actual object the +property would be defined on. In the Xray case that means obj is in the +target compartment (typically content) and `cx` is typically chrome. + +This extended attribute can be specified together with `[ChromeOnly]`, +and `[Pref]`. If more than one of these is specified, all conditions +will need to test true for the interface or interface member to be +exposed. + +Binding code will include the headers necessary for a `[Func]`, unless +the interface is using a non-default header file. If a non-default +header file is used, that header file needs to do any header inclusions +necessary for `[Func]` annotations. + +### `[Throws]`, `[GetterThrows]`, `[SetterThrows]` + +Used to flag methods or attributes as allowing the C++ callee to throw. +This causes the binding generator, and in many cases the JIT, to +generate extra code to handle possible exceptions. Possibly-throwing +methods and attributes get an `ErrorResult&` argument. + +`[Throws]` applies to both methods and attributes; for attributes it +means both the getter and the setter can throw. `[GetterThrows]` +applies only to attributes. `[SetterThrows]` applies only to +non-readonly attributes. + +For interfaces flagged with `[JSImplementation]`, all methods and +properties are assumed to be able to throw and do not need to be flagged +as throwing. + +### `[DependsOn]` + +Used for a method or attribute to indicate what the return value depends +on. Possible values are: + +* `Everything` + + This value can't actually be specified explicitly; this is the + default value you get when `[DependsOn]` is not specified. This + means we don't know anything about the return value's dependencies + and hence can't rearrange other code that might change values around + the method or attribute. + +* `DOMState` + + The return value depends on the state of the "DOM", by which we mean + all objects specified via Web IDL. The return value is guaranteed to + not depend on the state of the JS heap or other JS engine data + structures, and is guaranteed to not change unless some function with + [`[Affects=Everything]`](#affects) is executed. + +* `DeviceState` + + The return value depends on the state of the device we're running on + (e.g., the system clock). The return value is guaranteed to not be + affected by any code running inside Gecko itself, but we might get a + new value every time the method or getter is called even if no Gecko + code ran between the calls. + +* `Nothing` + + The return value is a constant that never changes. This value cannot + be used on non-readonly attributes, since having a non-readonly + attribute whose value never changes doesn't make sense. + +Values other than `Everything`, when used in combination with +[`[Affects=Nothing]`](#affects), can used by the JIT to +perform loop-hoisting and common subexpression elimination on the return +values of IDL attributes and methods. + +### `[Affects]` + +Used for a method or attribute getter to indicate what sorts of state +can be affected when the function is called. Attribute setters are, for +now, assumed to affect everything. Possible values are: + +* `Everything` + + This value can't actually be specified explicitly; this is the + default value you get when `[Affects]` is not specified. This means + that calling the method or getter might change any mutable state in + the DOM or JS heap. + +* `Nothing` + + Calling the method or getter will have no side-effects on either the + DOM or the JS heap. + +Methods and attribute getters with `[Affects=Nothing]` are allowed to +throw exceptions, as long as they do so deterministically. In the case +of methods, whether an exception is thrown is allowed to depend on the +arguments, as long as calling the method with the same arguments will +always either throw or not throw. + +The `Nothing` value, when used with `[DependsOn]` values other than +`Everything`, can used by the JIT to perform loop-hoisting and common +subexpression elimination on the return values of IDL attributes and +methods, as well as code motion past DOM methods that might depend on +system state but have no side effects. + +### `[Pure]` + +This is an alias for `[Affects=Nothing, DependsOn=DOMState]`. +Attributes/methods flagged in this way promise that they will keep +returning the same value as long as nothing that has +`[Affects=Everything]` executes. + +### `[Constant]` + +This is an alias for `[Affects=Nothing, DependsOn=Nothing]`. Used to +flag readonly attributes or methods that could have been annotated with +`[Pure]` and also always return the same value. This should only be +used when it's absolutely guaranteed that the return value of the +attribute getter will always be the same from the JS engine's point of +view. + +The spec's `[SameObject]` extended attribute is an alias for +`[Constant]`, but can only be applied to things returning objects, +whereas `[Constant]` can be used for any type of return value. + +### `[NeedResolve]` + +Used to flag interfaces which have a custom resolve hook. This +annotation will cause the `DoResolve` method to be called on the +underlying C++ class when a property lookup happens on the object. The +signature of this method is: +`bool DoResolve(JSContext*, JS::Handle<JSObject*>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>)`. +Here the passed-in object is the object the property lookup is happening +on (which may be an Xray for the actual DOM object) and the jsid is the +property name. The value that the property should have is returned in +the `MutableHandle<Value>`, with `UndefinedValue()` indicating that +the property does not exist. + +If this extended attribute is used, then the underlying C++ class must +also implement a method called `GetOwnPropertyNames` with the +signature +`void GetOwnPropertyNames(JSContext* aCx, nsTArray<nsString>& aNames, ErrorResult& aRv)`. +This method will be called by the JS engine's enumerate hook and must +provide a superset of all the property names that `DoResolve` might +resolve. Providing names that `DoResolve` won't actually resolve is +OK. + +### `[HeaderFile="path/to/headerfile.h"]` + +Indicates where the implementation can be found. Similar to the +headerFile annotation in Bindings.conf. Just like headerFile in +Bindings.conf, should be avoided. + +### `[JSImplementation="@mozilla.org/some-contractid;1"]` + +Used on an interface to provide the contractid of the [JavaScript +component implementing the +interface](#implementing-webidl-using-javascript). + +### `[StoreInSlot]` + +Used to flag attributes that can be gotten very quickly from the JS +object by the JIT. Such attributes will have their getter called +immediately when the JS wrapper for the DOM object is created, and the +returned value will be stored directly on the JS object. Later gets of +the attribute will not call the C++ getter and instead use the cached +value. If the value returned by the attribute needs to change, the C++ +code should call the `ClearCachedFooValue` method in the namespace of +the relevant binding, where `foo` is the name of the attribute. This +will immediately call the C++ getter and cache the value it returns, so +it needs a `JSContext` to work on. This extended attribute can only be +used on attributes whose getters are [`[Pure]`](#pure) or +[`[Constant]`](#constant) and which are not +[`[Throws]`](#throws-getterthrows-setterthrows) or [`[GetterThrows]`](#throws-getterthrows-setterthrows). + +So for example, given this IDL: + +``` webidl +interface MyInterface { + [Pure, StoreInSlot] attribute long myAttribute; +}; +``` + +the C++ implementation of MyInterface would clear the cached value by +calling +`mozilla::dom::MyInterface_Binding::ClearCachedMyAttributeValue(cx, this)`. +This function will return false on error and the caller is responsible +for handling any JSAPI exception that is set by the failure. + +If the attribute is not readonly, setting it will automatically clear +the cached value and reget it again before the setter returns. + +### `[Cached]` + +Used to flag attributes that, when their getter is called, will cache +the returned value on the JS object. This can be used to implement +attributes whose value is a sequence or dictionary (which would +otherwise end up returning a new object each time and hence not be +allowed in Web IDL). + +Unlike [`[StoreInSlot]`](#storeinslot) this does *not* cause the +getter to be eagerly called at JS wrapper creation time; the caching is +lazy. `[Cached]` attributes must be [`[Pure]`](#pure) or +[`[Constant]`](#constant), because otherwise not calling the C++ +getter would be observable, but are allowed to have throwing getters. +Their cached value can be cleared by calling the `ClearCachedFooValue` +method in the namespace of the relevant binding, where `foo` is the +name of the attribute. Unlike `[StoreInSlot]` attributes, doing so +will not immediately invoke the getter, so it does not need a +`JSContext`. + +So for example, given this IDL: + +``` webidl +interface MyInterface { + [Pure, StoreInSlot] attribute long myAttribute; +}; +``` + +the C++ implementation of MyInterface would clear the cached value by +calling +`mozilla::dom::MyInterface_Binding::ClearCachedMyAttributeValue(this)`. +JS-implemented Web IDL can clear the cached value by calling +`this.__DOM_IMPL__._clearCachedMyAttributeValue()`. + +If the attribute is not readonly, setting it will automatically clear +the cached value. + +### `[Frozen]` + +Used to flag attributes that, when their getter is called, will call +[`Object.freeze`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze) +on the return value before returning it. This extended attribute is only +allowed on attributes that return sequences, dictionaries and +`MozMap`, and corresponds to returning a frozen `Array` (for the +sequence case) or `Object` (for the other two cases). + +### `[BinaryName]` + +`[BinaryName]` can be specified on method or attribute to change the +C++ function name that will be used for the method or attribute. It +takes a single string argument, which is the name you wish the method or +attribute had instead of the one it actually has. + +For example, given this IDL: + +``` webidl +interface InterfaceWithRenamedThings { + [BinaryName="renamedMethod"] + undefined someMethod(); + [BinaryName="renamedAttribute"] + attribute long someAttribute; +}; +``` + +the corresponding C++ would be: + +``` cpp +class InterfaceWithRenamedThings +{ +public: + void RenamedMethod(); + int32_t RenamedAttribute(); + void SetRenamedAttribute(int32_t); +}; +``` + +### `[Deprecated="tag"]` + +When deprecating an interface or method, the `[Deprecated]` annotation +causes the Web IDL compiler to insert code that generates deprecation +warnings. This annotation can be added to interface methods or +interfaces. Adding this to an interface causes a warning to be issued +the first time the object is constructed, or any static method on the +object is invoked. + +The complete list of valid deprecation tags is maintained in +[nsDeprecatedOperationList.h](https://searchfox.org/mozilla-central/source/dom/base/nsDeprecatedOperationList.h). +Each new tag requires that a localized string be defined, containing the +deprecation message to display. + +### `[CrossOriginReadable]` + +Used to flag an attribute that, when read, will not have the same-origin +constraint tested: it can be read from a context with a different +origin. + +### `[CrossOriginWrite]` + +Used to flag an attribute that, when written, will not have the +same-origin constraint tested: it can be written from a context with a +different origin. + +### `[CrossOriginCallable]` + +Used to flag a method that, when called, will not have the same-origin +constraint tested: it can be called from a context with a different +origin. + +### `[SecureContext]` + +We implement the [standard extended +attribute](https://webidl.spec.whatwg.org/#SecureContext) with a few +details specific to Gecko: + +- System principals are considered secure. +- An extension poking at non-secured DOM objects will see APIs marked + with `[SecureContext]`. +- XPConnect sandboxes don't see `[SecureContext]` APIs, except if + they're created with `isSecureContext: true`. + +### `[NeedsSubjectPrincipal]`, `[GetterNeedsSubjectPrincipal]`, `[SetterNeedsSubjectPrincipal]` + +Used to flag a method or an attribute that needs to know the subject +principal. This principal will be passed as argument. If the interface +is not exposed on any worker global, the argument will be a +`nsIPrincipal&` because a subject principal is always available in +mainthread globals. If the interface is exposed on some worker global, +the argument will be a `const Maybe<nsIPrincipal*>&`. This `Maybe<>` +object contains the principal *only* on the main thread; when the method +is called on a {{domxref("Worker")}} thread, the value of the object +will be `Nothing()`. Note that, in workers, it is always possible to +retrieve the correct subject principal from the `WorkerPrivate` +object, though it cannot be used on the worker thread. + +`[NeedsSubjectPrincipal]` applies to both methods and attributes; for +attributes it means both the getter and the setter need a subject +principal. `[GetterNeedsSubjectPrincipal]` applies only to attributes. +`[SetterNeedsSubjectPrincipal]` applies only to non-readonly +attributes. + +### `[NeedsCallerType]` + +Used to flag a method or an attribute that needs to know the caller +type, in the `mozilla::dom::CallerType` sense. This can be safely +used for APIs exposed in workers; there it will indicate whether the +worker involved is a `ChromeWorker` or not. At the moment the only +possible caller types are `System` (representing system-principal +callers) and `NonSystem`. + +## Helper objects + +The C++ side of the bindings uses a number of helper objects. + +### `Nullable<T>` + +`Nullable<>` is a struct declared in +[`Nullable.h`](https://searchfox.org/mozilla-central/source/dom/bindings/Nullable.h) +and exported to `mozilla/dom/Nullable.h` that is used to represent +nullable values of types that don't have a natural way to represent +null. + +`Nullable<T>` has an `IsNull()` getter that returns whether null is +represented and a `Value()` getter that returns a `const T&` and can +be used to get the value when it's not null. + +`Nullable<T>` has a `SetNull()` setter that sets it as representing +null and two setters that can be used to set it to a value: +`void SetValue(T)` (for setting it to a given value) and +`T& SetValue()` for directly modifying the underlying `T&`. + +### `Optional<T>` + +`Optional<>` is a struct declared in +[`BindingDeclarations.h`](https://searchfox.org/mozilla-central/source/dom/bindings/BindingDeclarations.h) +and exported to `mozilla/dom/BindingDeclarations.h` that is used to +represent optional arguments and dictionary members, but only those that +have no default value. + +`Optional<T>` has a `WasPassed()` getter that returns true if a +value is available. In that case, the `Value()` getter can be used to +get a `const T&` for the value. + +### `NonNull<T>` + +`NonNull<T>` is a struct declared in +[`BindingUtils.h`](https://searchfox.org/mozilla-central/source/dom/bindings/BindingUtils.h) +and exported to `mozilla/dom/BindingUtils.h` that is used to represent +non-null C++ objects. It has a conversion operator that produces `T&`. + +### `OwningNonNull<T>` + +`OwningNonNull<T>` is a struct declared in +[`OwningNonNull.h`](https://searchfox.org/mozilla-central/source/xpcom/base/OwningNonNull.h) +and exported to `mozilla/OwningNonNull.h` that is used to represent +non-null C++ objects and holds a strong reference to them. It has a +conversion operator that produces `T&`. + +### Typed arrays, arraybuffers, array buffer views + +`TypedArray.h` is exported to `mozilla/dom/TypedArray.h` and exposes +structs that correspond to the various typed array types, as well as +`ArrayBuffer` and `ArrayBufferView`, all in the `mozilla::dom` +namespace. Each struct has a `Data()` method that returns a pointer to +the relevant type (`uint8_t` for `ArrayBuffer` and +`ArrayBufferView`) and a `Length()` method that returns the length +in units of `*Data()`. So for example, `Int32Array` has a `Data()` +returning `int32_t*` and a `Length()` that returns the number of +32-bit ints in the array. + +### `Sequence<T>` + +`Sequence<>` is a type declared in +[`BindingDeclarations.h`](https://searchfox.org/mozilla-central/source/dom/bindings/BindingDeclarations.h) +and exported to `mozilla/dom/BindingDeclarations.h` that is used to +represent sequence arguments. It's some kind of typed array, but which +exact kind is opaque to consumers. This allows the binding code to +change the exact definition (e.g., to use auto arrays of different sizes +and so forth) without having to update all the callees. + +### `CallbackFunction` + +`CallbackFunction` is a type declared in +[CallbackFunction.h](https://searchfox.org/mozilla-central/source/dom/bindings/CallbackFunction.h) +and exported to `mozilla/dom/CallbackFunction.h` that is used as a +common base class for all the generated callback function +representations. This class inherits from `nsISupports`, and consumers +must make sure to cycle-collect it, since it keeps JS objects alive. + +### `CallbackInterface` + +`CallbackInterface` is a type declared in +[CallbackInterface.h](https://searchfox.org/mozilla-central/source/dom/bindings/CallbackInterface.h) +and exported to `mozilla/dom/CallbackInterface.h` that is used as a +common base class for all the generated callback interface +representations. This class inherits from `nsISupports`, and consumers +must make sure to cycle-collect it, since it keeps JS objects alive. + +### `DOMString` + +`DOMString` is a class declared in +[BindingDeclarations.h](https://searchfox.org/mozilla-central/source/dom/bindings/BindingDeclarations.h) +and exported to `mozilla/dom/BindingDeclarations.h` that is used for +Web IDL `DOMString` return values. It has a conversion operator to +`nsString&` so that it can be passed to methods that take that type or +`nsAString&`, but callees that care about performance, have an +`nsStringBuffer` available, and promise to hold on to the +`nsStringBuffer` at least until the binding code comes off the stack +can also take a `DOMString` directly for their string return value and +call its `SetStringBuffer` method with the `nsStringBuffer` and its +length. This allows the binding code to avoid extra reference-counting +of the string buffer in many cases, and allows it to take a faster +codepath even if it does end up having to addref the `nsStringBuffer`. + +### `GlobalObject` + +`GlobalObject` is a class declared in +[BindingDeclarations.h](https://searchfox.org/mozilla-central/source/dom/bindings/BindingDeclarations.h) +and exported to `mozilla/dom/BindingDeclarations.h` that is used to +represent the global object for static attributes and operations +(including constructors). It has a `Get()` method that returns the +`JSObject*` for the global and a `GetAsSupports()` method that +returns an `nsISupports*` for the global on the main thread, if such +is available. It also has a `Context()` method that returns the +`JSContext*` the call is happening on. A caveat: the compartment of +the `JSContext` may not match the compartment of the global! + +### `Date` + +`Date` is a class declared in +[BindingDeclarations.h](https://searchfox.org/mozilla-central/source/dom/bindings/BindingDeclarations.h) +and exported to `mozilla/dom/BindingDeclarations.h` that is used to +represent Web IDL Dates. It has a `TimeStamp()` method returning a +double which represents a number of milliseconds since the epoch, as +well as `SetTimeStamp()` methods that can be used to initialize it +with a double timestamp or a JS `Date` object. It also has a +`ToDateObject()` method that can be used to create a new JS `Date`. + +### `ErrorResult` + +`ErrorResult` is a class declared in +[ErrorResult.h](https://searchfox.org/mozilla-central/source/dom/bindings/ErrorResult.h) +and exported to `mozilla/ErrorResult.h` that is used to represent +exceptions in Web IDL bindings. This has the following methods: + +- `Throw`: allows throwing an `nsresult`. The `nsresult` must be + a failure code. +- `ThrowTypeError`: allows throwing a `TypeError` with the given + error message. The list of allowed `TypeError`s and corresponding + messages is in + [`dom/bindings/Errors.msg`](https://searchfox.org/mozilla-central/source/dom/bindings/Errors.msg). +- `ThrowJSException`: allows throwing a preexisting JS exception + value. However, the `MightThrowJSException()` method must be called + before any such exceptions are thrown (even if no exception is + thrown). +- `Failed`: checks whether an exception has been thrown on this + `ErrorResult`. +- `ErrorCode`: returns a failure `nsresult` representing (perhaps + incompletely) the state of this `ErrorResult`. +- `operator=`: takes an `nsresult` and acts like `Throw` if the + result is an error code, and like a no-op otherwise (unless an + exception has already been thrown, in which case it asserts). This + should only be used for legacy code that has nsresult everywhere; we + would like to get rid of this operator at some point. + +## Events + +Simple `Event` interfaces can be automatically generated by adding the +interface file to GENERATED_EVENTS_WEBIDL_FILES in the +appropriate dom/webidl/moz.build file. You can also take a simple +generated C++ file pair and use it to build a more complex event (i.e., +one that has methods). + +### Event handler attributes + +A lot of interfaces define event handler attributes, like: + +``` webidl +attribute EventHandler onthingchange; +``` + +If you need to implement an event handler attribute for an interface, in +the definition (header file), you use the handy +"IMPL_EVENT_HANDLER" macro: + +``` cpp +IMPL_EVENT_HANDLER(onthingchange); +``` + +The "onthingchange" needs to be added to the StaticAtoms.py file: + +``` py +Atom("onthingchange", "onthingchange") +``` + +The actual implementation (.cpp) for firing the event would then look +something like: + +``` cpp +nsresult +MyInterface::DispatchThingChangeEvent() +{ + NS_NAMED_LITERAL_STRING(type, "thingchange"); + EventInit init; + init.mBubbles = false; + init.mCancelable = false; + RefPtr<Event> event = Event::Constructor(this, type, init); + event->SetTrusted(true); + ErrorResult rv; + DispatchEvent(*event, rv); + return rv.StealNSResult(); // Assuming the caller cares about the return code. +} +``` + +## `Bindings.conf` details + +Write me. In particular, need to describe at least use of `concrete`, +`prefable`, and `addExternalInterface`. + +### How to get a JSContext passed to a given method + +In some rare cases you may need a `JSContext*` argument to be passed +to a C++ method that wouldn't otherwise get such an argument. To see how +to achieve this, search for `implicitJSContext` in +[dom/bindings/Bindings.conf](#bindings-conf-details). + +## Implementing Web IDL using Javascript + +<div class="warning"><div class="admonition-title">Warning</div> + +Implementing Web IDL using Javascript is deprecated. New interfaces +should always be implemented in C++! + +</div> + +It is possible to implement Web IDL interfaces in JavaScript within Gecko +-- however, **this is limited to interfaces that are not exposed in Web +Workers**. When the binding occurs, two objects are created: + +- *Content-exposed object:* what gets exposed to the web page. +- *Implementation object:* running as a chrome-privileged script. This + allows the implementation object to have various APIs that the + content-exposed object does not. + +Because there are two types of objects, you have to be careful about +which object you are creating. + +### Creating JS-implemented Web IDL objects + +To create a JS-implemented Web IDL object, one must create both the +chrome-side implementation object and the content-side page-exposed +object. There are three ways to do this. + +#### Using the Web IDL constructor + +If the interface has a constructor, a content-side object can be created +by getting that constructor from the relevant content window and +invoking it. For example: + +``` js +var contentObject = new contentWin.RTCPeerConnection(); +``` + +The returned object will be an Xray wrapper for the content-side object. +Creating the object this way will automatically create the chrome-side +object using its contractID. + +This method is limited to the constructor signatures exposed to +webpages. Any additional configuration of the object needs to be done +methods on the interface. + +Creating many objects this way can be slow due to the createInstance +overhead involved. + +#### Using a `_create` method + +A content-side object can be created for a given chrome-side object by +invoking the static `_create` method on the interface. This method +takes two arguments: the content window in which to create the object +and the chrome-side object to use. For example: + +``` js +var contentObject = RTCPeerConnection._create(contentWin, new +MyPeerConnectionImpl()); +``` + +However, if you are in a JS component, you may only be able to get to +the correct interface object via some window object. In this case, the +code would look more like: + +``` js +var contentObject = contentWin.RTCPeerConnection._create(contentWin, +new MyPeerConnectionImpl()); +``` + +Creating the object this way will not invoke its `__init` method or +`init` method. + +#### By returning a chrome-side object from a JS-implemented Web IDL method + +If a JS-implemented Web IDL method is declared as returning a +JS-implemented interface, then a non-Web IDL object returned from that +method will be treated as the chrome-side part of a JS-implemented +WebIdL object and the content-side part will be automatically created. + +Creating the object this way will not invoke its `__init` method or +`init` method. + +### Implementing a Web IDL object in JavaScript + +To implement a Web IDL interface in JavaScript, first add a Web IDL file, +in the same way as you would for a C++-implemented interface. To support +implementation in JS, you must add an extended attribute +`JSImplementation="CONTRACT_ID_STRING"` on your interface, where +CONTRACT_ID_STRING is the XPCOM component contract ID of the JS +implementation -- note ";1" is just a Mozilla convention for versioning +APIs. Here's an example: + +``` webidl +[JSImplementation="@mozilla.org/my-number;1"] +interface MyNumber { + constructor(optional long firstNumber); + attribute long value; + readonly attribute long otherValue; + undefined doNothing(); +}; +``` + +Next, create an XPCOM component that implements this interface. Use +the same contract ID as you specified in the Web IDL file. The class +ID doesn't matter, except that it should be a newly generated one. For +`QueryInterface`, you only need to implement `nsISupports`, not +anything corresponding to the Web IDL interface. The name you use for +the XPCOM component should be distinct from the name of the interface, +to avoid confusing error messages. + +Web IDL attributes are implemented as properties on the JS object or its +prototype chain, whereas Web IDL methods are implemented as methods on +the object or prototype. Note that any other instances of the interface +that you are passed in as arguments are the full web-facing version of +the object, and not the JS implementation, so you currently cannot +access any private data. + +The Web IDL constructor invocation will first create your object. If the +XPCOM component implements `nsIDOMGlobalPropertyInitializer`, then +the object's `init` method will be invoked with a single argument: +the content window the constructor came from. This allows the JS +implementation to know which content window it's associated with. +The `init` method should not return anything. After this, the +content-side object will be created. Then,if there are any constructor +arguments, the object's `__init` method will be invoked, with the +constructor arguments as its arguments. + +### Static Members + +Static attributes and methods are not supported on JS-implemented Web IDL +(see [bug +863952](https://bugzilla.mozilla.org/show_bug.cgi?id=863952)). +However, with the changes in [bug +1172785](https://bugzilla.mozilla.org/show_bug.cgi?id=1172785) you +can route static methods to a C++ implementation on another object using +a `StaticClassOverride` annotation. This annotation includes the +full, namespace-qualified name of the class that contains an +implementation of the named method. The include for that class must be +found in a directory based on its name. + +``` webidl +[JSImplementation="@mozilla.org/dom/foo;1"] +interface Foo { + [StaticClassOverride="mozilla::dom::OtherClass"] + static Promise<undefined> doSomething(); +}; +``` + +Rather than calling into a method on the JS implementation; calling +`Foo.doSomething()` will result in calling +`mozilla::dom::OtherClass::DoSomething()`. + +### Checking for Permissions or Preferences + +With JS-implemented Web IDL, the `init` method should only return +undefined. If any other value, such as `null`, is returned, the +bindings code will assert or crash. In other words, it acts like it has +an "undefined" return type. Preference or permission checking should be +implemented by adding an extended attribute to the Web IDL interface. +This has the advantage that if the check fails, the constructor or +object will not show up at all. + +For preference checking, add an extended attribute +`Pref="myPref.enabled"` where `myPref.enabled` is the preference +that should be checked. `SettingsLock` is an example of this. + +For permissions or other kinds of checking, add an extended attribute +`Func="MyPermissionChecker"` where `MyPermissionChecker` is a +function implemented in C++ that returns true if the interface should be +enabled. This function can do whatever checking is needed. One example +of this is `PushManager`. + +### Example + +Here's an example JS implementation of the above interface. The +`invisibleValue` field will not be accessible to web content, but is +usable by the doNothing() method. + +``` js +function MyNumberInner() { + this.value = 111; + this.invisibleValue = 12345; +} + +MyNumberInner.prototype = { + classDescription: "Get my number XPCOM Component", + contractID: "@mozilla.org/my-number;1", + QueryInterface: ChromeUtils.generateQI([]), + doNothing: function() {}, + get otherValue() { return this.invisibleValue - 4; }, + __init: function(firstNumber) { + if (arguments.length > 0) { + this.value = firstNumber; + } + } +} +``` + +Finally, add a component and a contract and whatever other manifest +stuff you need to implement an XPCOM component. + +### Guarantees provided by bindings + +When implementing a Web IDL interface in JavaScript, certain guarantees +will be provided by the binding implementation. For example, string or +numeric arguments will actually be primitive strings or numbers. +Dictionaries will contain only the properties that they are declared to +have, and they will have the right types. Interface arguments will +actually be objects implementing that interface. + +What the bindings will NOT guarantee is much of anything about +`object` and `any` arguments. They will get cross-compartment +wrappers that make touching them from chrome code not be an immediate +security bug, but otherwise they can have quite surprising behavior if +the page is trying to be malicious. Try to avoid using these types if +possible. + +### Accessing the content object from the implementation + +If the JS implementation of the Web IDL interface needs to access the +content object, it is available as a property called `__DOM_IMPL__` on +the chrome implementation object. This property only appears after the +content-side object has been created. So it is available in `__init` +but not in `init`. + +### Determining the principal of the caller that invoked the Web IDL API + +This can be done by calling +`Component.utils.getWebIDLCallerPrincipal()`. + +### Throwing exceptions from JS-implemented APIs + +There are two reasons a JS implemented API might throw. The first reason +is that some unforeseen condition occurred and the second is that a +specification requires an exception to be thrown. + +When throwing for an unforeseen condition, the exception will be +reported to the console, and a sanitized NS_ERROR_UNEXPECTED exception +will be thrown to the calling content script, with the file/line of the +content code that invoked your API. This will avoid exposing chrome URIs +and other implementation details to the content code. + +When throwing because a specification requires an exception, you need to +create the exception from the window your Web IDL object is associated +with (the one that was passed to your `init` method). The binding code +will then rethrow that exception to the web page. An example of how +this could work: + +``` js +if (!isValid(passedInObject)) { + throw new this.contentWindow.TypeError("Object is invalid"); +} +``` + +or + +``` js +if (!isValid(passedInObject)) { + throw new this.contentWindow.DOMException("Object is invalid", "InvalidStateError"); +} +``` + +depending on which exact exception the specification calls for throwing +in this situation. + +In some cases you may need to perform operations whose exception message +you just want to propagate to the content caller. This can be done like +so: + +``` js +try { + someOperationThatCanThrow(); +} catch (e) { + throw new this.contentWindow.Error(e.message); +} +``` + +### Inheriting from interfaces implemented in C++ + +It's possible to have an interface implemented in JavaScript inherit +from an interface implemented in C++. To do so, simply have one +interface inherit from the other and the bindings code will +auto-generate a C++ object inheriting from the implementation of the +parent interface. The class implementing the parent interface will need +a constructor that takes an `nsPIDOMWindow*` (though it doesn't have +to do anything with that argument). + +If the class implementing the parent interface is abstract and you want +to use a specific concrete class as the implementation to inherit from, +you will need to add a `defaultImpl` annotation to the descriptor for +the parent interface in `Bindings.conf`. The value of the annotation +is the C++ class to use as the parent for JS-implemented descendants; if +`defaultImpl` is not specified, the `nativeType` will be used. + +For example, consider this interface that we wish to implement in +JavaScript: + +``` webidl +[JSImplementation="some-contract"] +interface MyEventTarget : EventTarget { + attribute EventHandler onmyevent; + undefined dispatchTheEvent(); // Sends a "myevent" event to this EventTarget +} +``` + +The implementation would look something like this, ignoring most of the +XPCOM boilerplate: + +``` js +function MyEventTargetImpl() { +} +MyEventTargetImpl.prototype = { + // QI to nsIDOMGlobalPropertyInitializer so we get init() called on us. + QueryInterface: ChromeUtils.generateQI(["nsIDOMGlobalPropertyInitializer"]), + + init: function(contentWindow) { + this.contentWindow = contentWindow; + }, + + get onmyevent() { + return this.__DOM_IMPL__.getEventHandler("onmyevent"); + }, + + set onmyevent(handler) { + this.__DOM_IMPL__.setEventHandler("onmyevent", handler); + }, + + dispatchTheEvent: function() { + var event = new this.contentWindow.Event("myevent"); + this.__DOM_IMPL__.dispatchEvent(event); + }, +}; +``` + +The implementation would automatically support the API exposed on +`EventTarget` (so, for example, `addEventListener`). Calling the +`dispatchTheEvent` method would cause dispatch of an event that +content script can see via listeners it has added. + +Note that in this case the chrome implementation is relying on some +`[ChromeOnly]` methods on EventTarget that were added specifically to +make it possible to easily implement event handlers. Other cases can do +similar things as needed. |