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
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
And remove redundant `Promise.resolve()` because it is the default
for async functions.
setIcon is not supported on Android, so there was no need to change
mobile/android/components/extensions/ext-pageAction.js.
MozReview-Commit-ID: 94ebaJFxLAi
This is only to help with migration. This change allows all APIs to
behave identical regardless of whether the API is proxied.
Change cloneScope to be a getter because cloneScope is
`this.contentWindow`, which may be nulled when the context navigates away
(but stays in the bfcache).
Any API that is not proxied must have an identical clone scope to make
sure that properties such as toJSON (in the native messaging
stringifier) and ArrayBuffer (in webRequest as requestBody) are visible
to the caller.
MozReview-Commit-ID: 9aT3SUBieHK
Neither the message manager nor the XUL browser is guaranteed to be
constant during a ProxyContext's lifetime.
Add a new class to follow the `<browser>` belonging to the current
docshell and update the ProxyContext properties as needed.
NOTE: The `BrowserDocshellFollower` class assumes that docshells are
swapped using `newBrowser.swapDocShells(oldBrowser)`. If this
assumption turns out to be false, then the tracker will lose track of
the `<browser>`. See bugzil.la/1301837 for more details.
Also, renamed `messageManager` to `currentMessageManager` because the
`messageManager` property is overwritten by the `setContentWindow` hack
in WannabeChildAPIManager in ExtensionChild.jsm.
browser/components/extensions/test/browser/browser_ext_currentWindow.js
provides test coverage for this feature once the `test` API goes through
a ChildAPIManager instead of directly through a WannabeChildAPIManager.
Why? Because that test calls `test.onMessage.addListener` in the script
that is loaded in a popup page. Popups are loaded in two stages: First
the content is preloaded in a `<browser>`, and then when the popup is
shown a new `<browser>` is created and the docshells are swapped.
When the script runs while the popup script is being preloaded, the
`ParentAPIManager` receives the IPC message with the target set to the
`<browser>` used for preloading. When the API response is ready,
`target.messageManager.sendAsyncMessage` is called. Meanwhile the
docshells have been swapped, the message manager is gone and this fails.
With this patch, the message manager is correctly tracked and this test
passes.
MozReview-Commit-ID: C5Z0ZJRXKyw
This is a simple move of ExtensionContext creation logic to
ExtensionChild.
Before the change, ExtensionContext was initialized as follows:
1. (ext-backgroundPage.js) Create background page
2. (Extension.jsm) document-element-inserted observed.
3. (Extension.jsm) new ExtensionContext + unload observer.
After this commit:
1. (ext-backgroundPage.js) Create background page
2. (ext-backgroundPage.js) emit extension-browser-inserted event
3. (Extension.jsm) Pass global to ExtensionContent + unload listener.
4. (ExtensionContent.jsm) document-element-inserted observed.
5. (ExtensionChild.jsm) new ExtensionContext
The next step is to use frame scripts and synchronize state.
MozReview-Commit-ID: K6mPdq7KQ2T
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
This is just a mechanical change, literally nothing more than cutting
ExtensionContext from Extension.jsm, pasting it in ExtensionChild.jsm
and adding the minimal imoort boilerplate.
MozReview-Commit-ID: 5uVt1IOdEFU
Currently, if the remote implementation is missing, the next unhelpful
error message is logged to the console:
"TypeError: findPathInObject(...) is not a function" or
"TypeError: findPathInObject(...) is undefined", etc.
This commit makes the message more useful:
"WebExtension API tabs.create not found (it may be unimplemented by Firefox)"
MozReview-Commit-ID: FhPEYKSjnLm
- 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
- 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
