WebIDL WebExtensions API Bindings¶
While on manifest_version: 2 all the extension globals (extension pages and content scripts)
that lives on the main thread and the WebExtensions API bindings can be injected into the extension
global from the JS privileged code part of the WebExtensions internals (See Schemas.inject defined in
Schemas.jsm),
in manifest_version: 3 the extension will be able to declare a background service worker
instead of a background page, and the existing WebExtensions API bindings can’t be injected into this
new extension global, because it lives off of the main thread.
To expose WebExtensions API bindings to the WebExtensions background.service_worker global
we are in the process of generating new WebIDL bindings for the WebExtensions API.
Warning
TODO: link to dom/webidl docs from this doc page for more general in depth details about WebIDL in Gecko.
Background Service Workers API Request Handling¶
Generating WebIDL definitions from WebExtensions API JSONSchema¶
WebIDL definitions for the extension APIs are being generated based on the WebExtensions API JSONSchema data (the same metadata used to generate the “privilged JS”-based API bindings).
Most of the API methods in generated WebIDL are meant to be implemented using stub methods shared
between all WebExtensions API classes, a WebExtensionStub webidl extended attribute specify
which shared stub method should be used when the related API method is called.
For more in depth details about how to generate or update webidl definition for an Extension API given its API namespace:
Wiring up new WebExtensions WebIDL files into mozilla-central¶
After a new WebIDL definition has been generated, there are a few more steps to ensure that the new WebIDL binding is wired up into mozilla-central build system and to be able to complete successfully a full Gecko build that include the new bindings.
For more in depth details about these next steps: