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
And change `this.global.Object.create(null)` to
`Cu.createObjectIn(this.global)`. The tests pass either way, but
`Cu.createObjectIn` is more explicit.
MozReview-Commit-ID: LmL6rTru5zZ
--HG--
extra : rebase_source : 4cf7b1463bf8b6882b6fd453657eae0ff43ed64d
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
- 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
- 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
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 main motive for this patch is to remove the use of the GlobalManager
global (which was used to see if an extension ID is valid, which was
specifically added in order to create thebrowser_ext_lastError.js test).
To preserve test coverage I implemented a full validation of the
runtime.sendMessage method.
Now the error for a non-existent extension is identical in both the
content script and background pages. Note that this also fixes a
minor privacy leak: Previously extensions could see whether another
extension is installed by sending a message to the specified extension
and using the different responses to see whether another extension is
installed.
MozReview-Commit-ID: 82R97Ei25Xr
--HG--
extra : rebase_source : 900a65e695afd6db83d5102f515dc29d46d001f1
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
The tabs.sendMessage and runtime.sendMessage implementations behave like
an async function: They take a callback parameter and return a promise.
So they should be handled by |callAsyncFunction|, not
|callFunctionNoReturn|.
This fixes the issue for background pages, but not for content scripts
because sendMessage is not implemented as a schema at the moment. This
will also be fixed once content script APIs are generated via Schemas.
MozReview-Commit-ID: 9p1hvOP0KSm
--HG--
extra : rebase_source : 7fc804e52184d59cc1dae2f299c644ed13d8a3c7
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
