This *mostly* gets us the latest WebIDL API of WebGPU. There is a few limits we are missing, and maybe some things I didn't notice.
But it gets us the new `GPUCanvasContext`, `GPUSupportedLimits`, and `GPUVertexStepMode`.
Differential Revision: https://phabricator.services.mozilla.com/D120764
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
This is a step towards removing object private slots.
Classes with JSCLASS_PRIVATE_IS_NSISUPPORTS now use JSCLASS_SLOT0_IS_NSISUPPORTS
instead. For most classes this means we need to add an extra reserved slot and remove
the private slot.
Global objects (SimpleGlobalObject and the XPConnect BackstagePass and Sandbox globals)
however can use the JSCLASS_GLOBAL_APPLICATION_SLOTS already there. These slots were
only used for WebIDL DOM globals until now.
Differential Revision: https://phabricator.services.mozilla.com/D119502
ExtensionMockAPI is a fake WebExtensions API, locked behind a pref and
used in unit tests related to the API requests handling and WebExtensionStub
methods without relying on a specific WebExtension API.
Depends on D84687
Differential Revision: https://phabricator.services.mozilla.com/D99886
The ExtensionPort represents the webidl definitions of the runtime.Port WebExtensions API object.
A webidl dictionary will represent the serializable definition of the port properties, sent from
the API request handler to provide all the internal properties needed to create an instance
of the ExtensionPort webidl interface on the worker thread (which will be returned to the
extension code as the return value of the runtime.connect/connectNative methods and as a
parameter of the calls to the runtime.onConnect API event listeners).
Depends on D84684
Differential Revision: https://phabricator.services.mozilla.com/D84685
WebIDL interface and c++ class to be used by all WebExtension API webidl bindings
to expose the expected WebExtensions API events (e.g. browser.tabs.onUpdated etc.)
Depends on D84682
Differential Revision: https://phabricator.services.mozilla.com/D80604
Define a new WebExtensionStub extended attribute in the WebIDL generator
to be used in the WebExtensions API WebIDL definitions.
Depends on D70372
Differential Revision: https://phabricator.services.mozilla.com/D84681
- Extension API WebIDL to be part of a new dom/extensions-webidl directory
(and all webidl in this directory associated with WebExtensions::General
bugzilla component)
- Extension API C++ implementation in a new toolkit/components/extensions/webidl-api
directory
- Lock Extensions API WebIDL bindings provided to extensions workers global on:
- the preference "extensions.backgroundServiceWorker.enabled" being set to true
- checking explicitly that the worker is an extension service worker declared
in the extension manifest.json file.
- Changes to WorkerPrivate, WorkerScope.h/.cpp to expose the WebIDL
bindings to the extension service workers (if the service worker has been
detected as the background service worker specified in the manifest),
plus small changes to RemoteWorkerChild.cpp to detect if the worker
is the background service worker (and mark it as so in the WorkerPrivate
instance associated to it)
Differential Revision: https://phabricator.services.mozilla.com/D70372
ExtensionMockAPI is a fake WebExtensions API, locked behind a pref and
used in unit tests related to the API requests handling and WebExtensionStub
methods without relying on a specific WebExtension API.
Depends on D84687
Differential Revision: https://phabricator.services.mozilla.com/D99886
The ExtensionPort represents the webidl definitions of the runtime.Port WebExtensions API object.
A webidl dictionary will represent the serializable definition of the port properties, sent from
the API request handler to provide all the internal properties needed to create an instance
of the ExtensionPort webidl interface on the worker thread (which will be returned to the
extension code as the return value of the runtime.connect/connectNative methods and as a
parameter of the calls to the runtime.onConnect API event listeners).
Depends on D84684
Differential Revision: https://phabricator.services.mozilla.com/D84685
WebIDL interface and c++ class to be used by all WebExtension API webidl bindings
to expose the expected WebExtensions API events (e.g. browser.tabs.onUpdated etc.)
Depends on D84682
Differential Revision: https://phabricator.services.mozilla.com/D80604
Define a new WebExtensionStub extended attribute in the WebIDL generator
to be used in the WebExtensions API WebIDL definitions.
Depends on D70372
Differential Revision: https://phabricator.services.mozilla.com/D84681
- Extension API WebIDL to be part of a new dom/extensions-webidl directory
(and all webidl in this directory associated with WebExtensions::General
bugzilla component)
- Extension API C++ implementation in a new toolkit/components/extensions/webidl-api
directory
- Lock Extensions API WebIDL bindings provided to extensions workers global on:
- the preference "extensions.backgroundServiceWorker.enabled" being set to true
- checking explicitly that the worker is an extension service worker declared
in the extension manifest.json file.
- Changes to WorkerPrivate, WorkerScope.h/.cpp to expose the WebIDL
bindings to the extension service workers (if the service worker has been
detected as the background service worker specified in the manifest),
plus small changes to RemoteWorkerChild.cpp to detect if the worker
is the background service worker (and mark it as so in the WorkerPrivate
instance associated to it)
Differential Revision: https://phabricator.services.mozilla.com/D70372
ExtensionMockAPI is a fake WebExtensions API, locked behind a pref and
used in unit tests related to the API requests handling and WebExtensionStub
methods without relying on a specific WebExtension API.
Depends on D84687
Differential Revision: https://phabricator.services.mozilla.com/D99886
The ExtensionPort represents the webidl definitions of the runtime.Port WebExtensions API object.
A webidl dictionary will represent the serializable definition of the port properties, sent from
the API request handler to provide all the internal properties needed to create an instance
of the ExtensionPort webidl interface on the worker thread (which will be returned to the
extension code as the return value of the runtime.connect/connectNative methods and as a
parameter of the calls to the runtime.onConnect API event listeners).
Depends on D84684
Differential Revision: https://phabricator.services.mozilla.com/D84685
WebIDL interface and c++ class to be used by all WebExtension API webidl bindings
to expose the expected WebExtensions API events (e.g. browser.tabs.onUpdated etc.)
Depends on D84682
Differential Revision: https://phabricator.services.mozilla.com/D80604
Define a new WebExtensionStub extended attribute in the WebIDL generator
to be used in the WebExtensions API WebIDL definitions.
Depends on D70372
Differential Revision: https://phabricator.services.mozilla.com/D84681
- Extension API WebIDL to be part of a new dom/extensions-webidl directory
(and all webidl in this directory associated with WebExtensions::General
bugzilla component)
- Extension API C++ implementation in a new toolkit/components/extensions/webidl-api
directory
- Lock Extensions API WebIDL bindings provided to extensions workers global on:
- the preference "extensions.backgroundServiceWorker.enabled" being set to true
- checking explicitly that the worker is an extension service worker declared
in the extension manifest.json file.
- Changes to WorkerPrivate, WorkerScope.h/.cpp to expose the WebIDL
bindings to the extension service workers (if the service worker has been
detected as the background service worker specified in the manifest),
plus small changes to RemoteWorkerChild.cpp to detect if the worker
is the background service worker (and mark it as so in the WorkerPrivate
instance associated to it)
Differential Revision: https://phabricator.services.mozilla.com/D70372
There's a pattern of clearing JS things when calling mozilla::DropJSObjects,
but mozilla::DropJSObjects already clears the JS things itself by calling
CycleCollectedJSRuntime::RemoveJSHolder.
Differential Revision: https://phabricator.services.mozilla.com/D115885
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
Most of the time, a lot of the WebIDL interfaces are never used with Xray wrappers.
We still always initialise the necessary PropertyInfo arrays whenever they're used
normally (not through Xray wrappers). I think we should postpone that initialisation
until we're actually going to use them with Xray wrappers.
Differential Revision: https://phabricator.services.mozilla.com/D114402
Most of the time, a lot of the WebIDL interfaces are never used with Xray wrappers.
We still always initialise the necessary PropertyInfo arrays whenever they're used
normally (not through Xray wrappers). I think we should postpone that initialisation
until we're actually going to use them with Xray wrappers.
Differential Revision: https://phabricator.services.mozilla.com/D114402
For [Global] WebIDL interfaces, properties from the property array are installed
on the object itself, instead of on the prototype. To fix the bug I changed how
we install the @@toStringTag property, instead of adding it in the property
array of every interface we'll now instead install the property directly in
CreateInterfacePrototypeObject, which is also a codesize win. This does mean
that we need to look up the value dynamically in XrayResolveOwnProperty (we
can't resolve it from the property array anymore), but luckily we can use
NamesOfInterfacesWithProtos for that.
Differential Revision: https://phabricator.services.mozilla.com/D113664
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150