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
Tom Schuster
Luca Greco
Alexandru Michis
Csoregi Natalia
Andrey Bienkowski
Dorel Luca
Peter Van der Beken
Andreas Farre
Mike Hommey
Andi-Bogdan Postelnicu
Alex Lopez
Edgar Chen
Karl Tomlinson
Iulian Moraru