- Combine the errors for a non-existing app and lacking permissions to
avoid information leakage.
- Do not treat normal application exit as an error.
- Create errors in the right context.
- Add tests that check the error messages.
MozReview-Commit-ID: HxBpeCSyyGN
--HG--
extra : rebase_source : f9406cec6bddd4ab740f5042dd7cc64d4a63e447
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
--HG--
extra : rebase_source : be44523ca1b6555f5c356f12790c896e781d809f
This communicates more clearly that we expect only one message/event.
MozReview-Commit-ID: 8jDYBVwqQtz
--HG--
extra : rebase_source : acae1570537b17027901253afc2344ffabd7a9ee
The extension is always available as `context.extension`, so do not
unnecessarily pass the extension as a separate parameter.
MozReview-Commit-ID: 9OaestUAGVk
--HG--
extra : rebase_source : b1f408d3750152477195655c5a777e1ff4682a09
Serialization of the message should happen in the same process as the
extension context, whereas sending the message should be in the same
process as the owner of the native messaging host.
With webext-oop, the former is an addon process and the latter the
main process. Therefore it is necessary to separate the two roles.
MozReview-Commit-ID: 8BJZmn2QjLJ
--HG--
extra : rebase_source : d0665885c304b45c2f44e82f29c1a8260fe454c5
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
--HG--
extra : rebase_source : 16687b2acfccaecec0b39a4a3d9f86e91431ee55
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
--HG--
extra : rebase_source : 341c0dfa2531dd6137976eb8dfaed16edc5bbd51
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
--HG--
extra : rebase_source : b91d701bba21f376935961a6eeb1a8489ac5591b
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
--HG--
extra : rebase_source : ef12309acc2060b9a2b2bc55be72b95d0f4f450e
Added 2 probes:
1. Breakup by language of initilizations and available voice support for that language.
2. Speak time of narrate.
MozReview-Commit-ID: AGD8nON2m7N
--HG--
extra : rebase_source : 2bbd483bf48b92e290e726cea4f16c6ff5155b58
This removes the obsolete toolkit directory. A few references to dialogOverlay
have been updated to just used <dialog> directly. The InlineSpellCheckerUI var
has also been moved directly to browser.js and defined as lazy getter.
MozReview-Commit-ID: JZfi0W2wqCL
There is a timing-sensitive bug in window.create and/or cookies API.
I haven't figured out the exact details, but created a minimal
test case and reported it at bugzil.la/1309637
Without this patch, the test will fail as described in that bug report.
MozReview-Commit-ID: DiJOao8h8Q7
--HG--
extra : rebase_source : 6a24f2570799cf113e544c68ef3d69645991e4a3
We need to advertise this to the update server to avoid downloading
updates which won't run because of unsupported cpu features on
the recipient's hardware.
MozReview-Commit-ID: H36VXnD3TnW
--HG--
extra : rebase_source : ec382626f96f4f863b9ed44c5aec529d541815b9
Bug 1293365 fixed the query in `Bookmarks.reorder` to leave missing
entries in place, instead of moving them to the end of the folder. It
also correctly ignores nonexistent children, so we can
remove all the extra logic in `PlacesSyncUtils`.
We can also use a map instead of two linear searches to look up
indices in the `Bookmarks.reorder` sorting function. This reduces the
time to sort an array of 10k children from 30 seconds to less than a
second on my dev machine.
MozReview-Commit-ID: G9vuC12JXq4
--HG--
extra : rebase_source : 402e55b44f43a672d847f1f457bcb3538819e341
The onUpdateAvailable listener is asynchronously notified, so the caller
(i.e. the test) cannot assume that a message sent immediately after
triggering an update would trigger the `browser.test.onMessage` listener
that was added in the onUpdateAvailable event handler.
MozReview-Commit-ID: 12n64f5l3RA
--HG--
extra : rebase_source : 6ba7923359786c4ccd7f4d29664a8567e253e0cd
The test logic was broken by design: Two tests uninstall the addon,
but only one uninstall observer was used. Consequently, the second
test resumes the test before the addon was actually uninstalled.
It is probably sheer luck that the test worked before.
MozReview-Commit-ID: DcT48ZQ2bRp
--HG--
extra : rebase_source : 6ab304eab2c306106b5383726fbdf73775c5060a
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
--HG--
extra : rebase_source : 0464a1aa2387343a6f1d0fcd8fbabfdd1a68b1bb
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
--HG--
extra : rebase_source : 20466181501b264ba33fc8ab61fdf2bed20f9eef
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
--HG--
extra : rebase_source : f5e4eef52100e42b6fcdc3a43fa7676e7fc3dabc
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
--HG--
extra : rebase_source : 63e6c408d0e7f58dca81810771810cf6fe7b5d5b
