Sending MessageManager messages is expensive, but a lot of the overhead is
per-message more than it's tied to the complexity of the message. In
particular:
- Each sendAsyncMessage call incurs separate XPConnect method call overhead.
- Each message requires acquiring a lock, and separate message setup overhead
for IPC.
- The message data itself must be structured cloned, which requires
(expensive) allocation of buffers to hold the serialized data. Each buffer
segment is 4KB, which is generally enough to hold multiple serialized
messages, so coalescing messages means fewer buffer allocations.
Moving some of this work into idle slices also means less likelihood of
interfering with UI responsiveness.
MozReview-Commit-ID: 5SAMZNLVaY3
Pending responses are normally removed by the response's promise handlers. But
since promise handlers are called asynchronously, multiple calls to
abortResponses can wind up handling the same already-aborted responses when
called before we process the microtask queue.
MozReview-Commit-ID: 4jy0O7PaoqP
- 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
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
