Move `runtime.connectNative` and `runtime.sendNativeMessage` to
`addon_child`. Note: This does not change the behavior for launching the
native app, it is still launched from the main process.
Now ExtensionUtils's Port is also used for native messaging ports. Now
the behavior of `runtime.connect` and `runtime.connectNative` are
identical from the extension's perspective.
In particular:
- `disconnect()` does not throw when called again (bug 1287229).
- `onDisconnect` is called with error messages (tests will be added in
the next commit).
MozReview-Commit-ID: AyU9amiLeoL
In Chrome, runtime.lastError is set when the port is disconnected
due to an error.
Here in Firefox we choose to set a new property "error" on the port
if the port disconnected due to an error.
Since onDisconnect fires at most once, port.error is set only once.
MozReview-Commit-ID: EPaVtV4WkcQ
Unify implementation of fire and fireWithoutClone. `fireWithoutClone`
was running the callbacks synchronously. After this commit the callback
is run asynchronously. This is safe because the only user of this method
is `Port`'s `onDisconnect`.
MozReview-Commit-ID: 1kiYavsu3e7
This should have been a part of bug 1298810, but that only set the
argument for native messaging ports, which does not use Port from
ExtensionUtils. The port parameter must also be included in runtime's
Port.onMessage to avoid regressions when the port implementations are
unified and native messaging starts using runtime's Port.
Note that starting from this commit, multiple onMessage listeners
receive the same (cloned) message instead of a new clone per listener.
This is a side effect of using `fire.withoutClone` instead of `fire`:
`fire` clones all parameters, but ports are not cloneable so we have
to use `fire.withoutClone` instead. This change with regards to message
cloning is fully compatible with Chrome's messaging API (which also
passes the same message object to all `port.onMessage` calls).
MozReview-Commit-ID: AUDuUKHkXCM
Decoupled the API from the implementation. From now on it is possible
to create Port instances without generating an API. This allows us to
internally use Ports to pass around messages with minimal overhead
(in the form of unnecessary clones of messages).
This will be used by native messaging.
This commit has no behavioral change, it is mostly moving around some
code and storing the internal message listener in a set.
MozReview-Commit-ID: 4h0LNJvTH9R
Main thing: Making contextMenus implementation webext-oop compatible.
Preparation:
- Add getParentEvent to ChildAPIManager to allow use of remote events.
- Introduce `addon_parent_only` to "allowedContexts" to only generate a
schema API in the main process.
- Do not fill in `null` for missing keys if the schema declares a key as
`"optional": "omit-key-if-missing"`. This is needed for the second
point in the next list.
Drive-by fixes:
- Ensure that the "onclick" handler is erased when a context closes.
- Do not clear the "onclick" handler in `contextMenus.update` if the
onclick key has been omitted (parity with Chrome).
- Remove some unnecessary `Promise.resolve()`
- Add extensive set of tests that check the behavior of the contextMenus
APIs with regards to the onclick attribute in various scenarios.
MozReview-Commit-ID: A5f3AUQzU8T
The `browser.downloads.download` API takes a "url" parameter. The schema
file at downloads.json defines the type to be "url". This means that the
parameter is checked with `context.checkLoadURL(url)` in Schemas.jsm.
This method uses the principal of the object that was passed to
`Schemas.inject`.
Currently, this works just fine because the `schemaWrapper` in
Extension.jsm returns the context's principal.
But when we move to using the ChildAPIManager, the principal is not
defined and Schemas.jsm will fall back to a Null principal.
As a result, the test_ext_downloads_download.js fails because the
blob:-URL with the extension origin cannot be loaded by a null
principal. To fix this, the context's principal must be set.
MozReview-Commit-ID: FmpqYfPemyY
This is the bare minimum to separate the generation of addon_parent and
addon_child APIs. Now it is possible to have methods with the same name
but different implementations in the parent and child.
Many APIs are not compatible with the proxied API implementation, so
they temporarily fall back to directly invoking the parent API, just as
before this commit.
MozReview-Commit-ID: fwuZUvD8tY
With an upcoming change that introduces another ProxyContext,
errors from a different scope may bubble up. These messages should
be reported, not replaced with "An unexpected error occurred".
MozReview-Commit-ID: ByUktVkhDyx
- Add callParentFunctionNoReturn / callParentAsyncFunction to
ChildAPIManager to implement remote calls.
- Add in-process browser.test implementation that uses this.
- Add tests to verify that the browser.test.assert* methods with
the `allowAmbiguousOptionalArguments` schema attribute are working
with objects that cannot be passed as-is over IPC.
(except test.sendMessage, because stringifying the arguments has an
observable impact on test behavior)
MozReview-Commit-ID: 6cFVgmFfU93
- removeListener: There is no set.remove, use set.delete.
- Async callbacks: Do not unconditionally turn the result in a
SpreadArgs because it causes the result to unconditionally
be wrapped in an array (+test).
MozReview-Commit-ID: LqwtBsHWJJr
- Make all keys in `filter` mandatory.
- Add `optionalFilter` to Messenger to take over the role of the former
`filter` parameter.
- Add documentation to Messenger to explain what it really does.
- Fix type comments. Many message message managers were declared as a
sender, while they are at most a receiver (e.g. `Services.pppm`).
MozReview-Commit-ID: ILDnP2qDIK9
- 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
- Add new responseType RESPONSE_NONE to MessageChannel to signal no
expected reply.
- Modify Port to use MessageChannel instead of message managers.
- Include the `port` object to the disconnect event of ports because
Chrome does it too.
- Replace use of `contentWindow` with `cloneScope` to make the Port
independent of documents.
- Move registration of context destruction from `api()` to the
constructor to make sure that the disconnect listener is properly
removed if for some reason the `api` method is never called.
MozReview-Commit-ID: 9LCo5x1kEbH
`this.sender` has a tabId, `sender.tab` has a tab object. Therefore
they are not equal, and as a result messages were sent to the same
frame. Fixed by relying on contextId, which is unique across processes
since bug 1288279.
MozReview-Commit-ID: 8jMoXiBfp6l
callbacks is not an array but a Set, and Object.freeze does not prevent
modification of the list/set. Also, merely overwriting the callback set
is not sufficient to prevent callbacks from being run after the context
is closed (`fireWithoutClone`) because the set being iterated is still
filled with callbacks. And keeping the callbacks around may keep strong
references around and hinder GC.
To fix this, the set of callbacks is cleared (which invalidates the
iterator and ends the loop), and register/unregister are nulled.
Also add an explicit check to prevent callbacks from being registered
after unloading a context.
MozReview-Commit-ID: 4i2ojkbYAX9
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
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
- 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
- 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
- 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
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
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
