- 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
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
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
