This patch introduces helper for the embedding of a webextension (and new related tests).
The new exported helpers are going to be integrated in the XPIProvider
to provide the Embedded WebExtension to the Legacy Extensions which
have enabled it in their install.rdf
MozReview-Commit-ID: 7M1DRkXjGat
--HG--
extra : rebase_source : 3226a83652b97601d9d4d34693761cfc720735a0
- this new module contains helpers to be able to receive connections
originated from a webextension context from a legacy extension context
(implemented by the `LegacyExtensionContext` class exported from
this new jsm module)
- two new test files (an xpcshell-test and a mochitest-browser) ensures that the LegacyExtensionContext can receive a Port
object and exchange messages with a background page and a content script (the content script test
is in a different test file because it doesn't currently work on android, because it needs
the browser.tabs API and the TabManager internal helper)
MozReview-Commit-ID: DS1NTXk0fB6
--HG--
extra : rebase_source : 462d6a461167e317297d204e72c2f6773bc5c770
Split the `shouldInject` method into separate methods:
- `shouldInject` to determine whether the API (or namespace)
should be injected.
- `getImplementation` to return the actual implementation.
Introduced `SchemaAPIInterface` for documentation purposes, and
two concrete implementations `LocalAPIImplementation` and
`ProxyAPIImplementation` which provide the functionality to run a local
and remote implementation of the API for which the schema API is
generated, respectively. These classes store the necessary details for
the invocation, so the methods that were formerly in the `Context` in
Schemas.jsm no longer get the `pathObj`, `path` or `name` parameters.
And merge the `path` and `name` in the implementation of remote APIs
because there is no need for having them separate, as the callers and
callees often did redundant pre/post-processing on `data.path` because
of the way it was implemented.
MozReview-Commit-ID: isbG9i9pNP
--HG--
extra : rebase_source : 22cdc3ab3d14c6381f9f540739d6750281ae8c71
The API implementation is already available upfront when the schema API
is generated, so `pathObj` has the implementation and can be used
instead of looking up the implementation over and over again with
`findPathInObject`.
MozReview-Commit-ID: FnCIyoaxgA4
--HG--
extra : rebase_source : 440b25fcfb4a0438b1ff8680ad770930e7427de7
- This was the last non-schema-generated API in content scripts.
MozReview-Commit-ID: FaIOCHoircf
--HG--
extra : rebase_source : 7bab2249a7462a581e493f7aa937df45cb895107
- By default, schema APIs are not injected in content scripts unless
the JSON schema sets the "restrictions" attribute to `["content"]`.
- Added the "restrictions" attribute to the storage and test schemas.
Other APIs will follow in subsequent commits and make use of the
primitives introduced in this commit.
MozReview-Commit-ID: 1rNjQap0BiM
--HG--
extra : rebase_source : bf2c7fb70a38fbf13cdfd4337cb3cb6fef7e67e8
- Moved Management logic to ExtensionUtils (as SchemaAPIManager) so that
the logic can be used by addon and content processes.
- Remove the `context.extension.hasPermission(api.permission)` check in
`generateAPIs` because the only user (`registeredPrivilegedAPI`) was
removed before in bug 1295082.
- Add new category "webextension-scripts-content", intended for
registering the few scripts that must be loaded in a content process.
MozReview-Commit-ID: 81nhblV8YE6
--HG--
extra : rebase_source : d2eee0298ad5038225ea56c2e752532af0bc6fb7
- Add `envType` to BaseContext.
- Pass an explicit envType to all `registerSchemaAPI` invocations.
- The factories passed to `registerSchemaAPI` will be split up later, so
that content scripts (`content_child`) and addon pages can share
common implementations.
- The factories that implement the addon API will also be split up,
to separate code running in the main process (`addon_parent`) from
code running in a child process (`addon_child`).
- Remove the use of a hardcoded list of `namespaces` from ProxyContext.
Now `envType` is used to specify whether an API should be activated.
MozReview-Commit-ID: Jiff8HIwG92
--HG--
extra : rebase_source : 946a3c0009a4e3223c2d10044b3099a94c845394
Local wrappers currently look up the API object over and over again
whenever a schema API is invoked. This can be optimized by re-using
the lookup result from a `shouldInject` invocation, which is passed
as the `pathObj` parameter to the wrapper methods.
This commit adds the necessary changes and tests to allow this to
happen, but does not modify the wrapper in Extension.jsm yet.
Also, this construction allows the `ChildAPIManager` to use a local
implementation if available and fall back to a remote implementation
otherwise.
MozReview-Commit-ID: C9gm7A9Zppb
--HG--
extra : rebase_source : e2ab1e40de72fdea23acc9a68f3cf7d77e3da66f
Currently there is a tight coupling between registered APIs because they
share the same global scope, and the dependencies between the modules
that use these globals are not explicit. Consequently, it would be
possible for APIs to break when the registered APIs run in separate
processes, because then there are separate global scopes.
To mitigate this issue, this patch isolates the global namespaces of
API registrations in different environments, starting with the "chrome"
process. Content and addon processes will follow later.
A new JSM is introduced to avoid hidden dependencies between ext-*.js
and the script loader. ExtensionUtils.jsm would be a natural choice for
this shared utility method, but cannot be used because its local
`EventEmitter` implementation conflicts with the `EventEmitter` import
in ext-tabs.js.
So, this patch provides isolation of global variables declared through
`globals.XXX = ...`, but does not provide isolation for `Cu.import`-ed
logic. Ideally `Cu.import` should always use its second argument to
prevent inadvertent namespace pollution.
MozReview-Commit-ID: 1DTZaKOaeSE
--HG--
extra : rebase_source : 1376a1325fd9bf186e09e1dbe83467f3ad94516f
It is not directly related to the current bug but I added a test
for browser.extentionTypes while I was here.
MozReview-Commit-ID: 2XifKm3ZhrY
--HG--
extra : rebase_source : 855e44ebf7d595211de46a0ecbfedca107430662
The presence of these globals interfere with the attempt to get ext-*.js
scripts to load in a content process because these globals are only
available in the main process.
MozReview-Commit-ID: 7syjAGcuUnu
--HG--
extra : rebase_source : d614424d50bbb2a5dea6c23e4dae1586b9efe4fb
ExtensionContext in Extension.jsm has |extension| as an instance member,
so use it instead of passing |extension| to registerSchemaAPI's
callback.
And to make sure that this pattern also works in content processes, move
the |extension| member to BaseContext.
MozReview-Commit-ID: BgsGGCPQxJR
--HG--
extra : rebase_source : 7aa9fb7a53e057e8d3d8c477bd6821f8344c571a
ExtensionContext in Extension.jsm has |extension| as an instance member,
so use it instead of passing |extension| to registerSchemaAPI's
callback.
And to make sure that this pattern also works in content processes, move
the |extension| member to BaseContext.
MozReview-Commit-ID: BgsGGCPQxJR
--HG--
extra : rebase_source : 9a85d95f0c147198938b86c57127f6e7403fd53c
needed to be able to return null when the registered schema API should not be available
based on the context type instead of WebExtensions permissions.
MozReview-Commit-ID: G8w8ZYzmA7S
--HG--
extra : rebase_source : 7cacd2d5b5c0e1ef354e2cef19c7d809cc632470
Prior to this change, SpecialPowers used the extension id to identiy
extension instances in inter-process messaging. This required that
an id be allocated from the content process side when loadExtension()
was called, but that made it impossible to test code that exercises the
code path in the AddonManager that allocates ids for extensions that do
not include an id in the manifest (it also made the loadExtension() api
clunky).
With this change, SpecialPowers allocates an internal identifier for
messaging, but this identifier is separate from extension ids.
Confusingly, we still store the actual extension id in an id property
on the object returned by loadExtension(), but there are enough tests
that reference this that it would be unnecessarily disruptive to get
rid of it so it stays for now...
MozReview-Commit-ID: G6xk1mBJJL8
--HG--
extra : rebase_source : a0891e5ba308972c35813f55274badf9edde62f7
extra : source : e8818ef3c28489e196d1db92cabf224861b693c9
