- 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
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
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
Tests cannot be run in a new process, so when this test is run along
with other tests, the faulty behavior is not caught.
You can manually check whether the bug is still present by running the
test in isolation:
mach mochitest browser/components/extensions/test/browser/browser_ext_webNavigation_frameId0.js
MozReview-Commit-ID: LwumSU7zh8R
--HG--
extra : rebase_source : c09fae54cd94af90d7d5391361b33532df6a8d72
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
This doesn't include tests for this behavior, because I'm not sure there's a
good way to test it reliably.
MozReview-Commit-ID: CM5rj1f9YiG
--HG--
extra : rebase_source : 11608a2d0b78802021a4f8aec39f0caa2f75af2c
