Call tabs.create immediately after the tab is created without delay to
reduce the chance of losing tabs.onUpdated events.
If needed, the tab waiting is done by `executeScript`, etc.
MozReview-Commit-ID: 7A1zH99zafK
- Use the frame's message manager to direct messages via the
ProxyMessenger to the right tab instead of directly to the tab.
- Put the implementation in a separate file that is only loaded in
child processes (in the future).
- Explicitly list all addon-process specific files in a new category
instead of reusing the content one.
MozReview-Commit-ID: 8oIMx9ol7Tl
LegacyExtensionContext should inherit from BaseContext instead of
ExtensionContext, because the latter is moving to a separate process.
Remove the optional `url` parameter because the context is not a frame.
`url` is assigned to `sender.url`, which should only be set for frames.
The sender is only used in extension messaging when `runtime.connect` or
`runtime.sendMessage` are used (where `sender.url` is visible at the
receiver). Since legacy extensions don't send messages, there is no
point at all in setting the `url` value.
MozReview-Commit-ID: FJboNC2SZh0
- Introduce a proxy for IPC messages to allow the following APIs
to be run out-of-process (ProxyMessenger):
* runtime.connect
* runtime.sendMessage
* tabs.connect
* tabs.sendMessage
* runtime.onConnect
* runtime.onMessage
- Update getSender in ext-tabs, make it independent of the context
(in particular do not throw an error when a message is received while
the tab is gone), and move it from MessageChannel to ProxyMessenger to
make sure that it works in webext-oop. MessageChannel lives in a child
process, whereas the TabManager (used by getSender) requires data from
the main process.
- Set the third parameter of `addMessageListener` to true in some places
to make sure that messages get delivered even after unloading the
context. This is needed for the next two points.
- Put the `messageManager` property in BaseContext, and let it be set by
`setContentWindow` - runtime.sendMessage/connect and tabs.sendMessage/
connect depends on this property, and using the frame message manager
makes sense.
- Unconditionally use the frame message manager in
runtime.sendMessage/connect instead of sometimes the cpmm.
MozReview-Commit-ID: 4QkPnlMOkjS
the tabs.onUpdated event can fire for many reasons.
I observed a test failure because a faviconUrl change triggered the
onUpdated event, which caused on-updated-dims to be sent too early.
MozReview-Commit-ID: 8YT8hSXnIoo
- 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
- 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
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
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
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
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
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
