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 ProxyMessenger registers a listener whenever the first addon
starts. Although the map does not have any listeners any more at
the end of the test, the listener itself is not removed because
the message-manager-close notification is not sent for them.
So do not count these persistent message managers in the test.
The actual message managers of interest are those associated with
the (closed) tab.
Note: When the test is run in isolation, it may still fail due
to bugzil.la/1293583. See bug for work-around if you want to test.
MozReview-Commit-ID: IiDHhmvQPcv
--HG--
extra : rebase_source : 3a9332d69be31e34bc704de217c823e2a02dd514
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
In one of the previous patches, the viewType of popup changed from
"popup" to "tab". As a result it was closed by the `page-shutdown`
event handler in ext-tabs.js. This prevents that from happening.
Also added a test that checks whether the options page type is a tab, to
prevent future regressions.
MozReview-Commit-ID: 3Qcf08PgNqb
--HG--
extra : rebase_source : c4b89d122df52a7280ff5818903cb1d8737fb31c
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
--HG--
extra : rebase_source : c8f96765cc05fc4a3631120ae4546d6a8512c840
"extension.views" will only be available in content, so
use the "proxy-context-load" event to detect new views.
MozReview-Commit-ID: K86Be5IDk42
--HG--
extra : rebase_source : 97c839efacbb9981399462d712766b5410567bae
Accessing <browser> in ContentChild does not work when extensions run in
a separate process.
MozReview-Commit-ID: EK0aOYeGaZ5
--HG--
extra : rebase_source : 359cb1f9022b8097d27aa74a30e133c4a7e7c742
browser.test.sendMessage does not have enough time to finish
before tabs.remove since test moved to ChildAPIManager for
extension pages, causing the test to time out.
MozReview-Commit-ID: 1mmGZOi9fzm
--HG--
extra : rebase_source : b0d1310f867040f1f7d14b94a95ba364e3902f88
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
--HG--
extra : rebase_source : c742dfe89646d6717da134c7408aa5a066107c66
"viewType" is more easily searchable and not as ambiguous as "type".
MozReview-Commit-ID: 8sG4qagFCBu
--HG--
extra : rebase_source : 39d76379996e631b9fc33f0c77d565cf302b9df9
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
--HG--
extra : rebase_source : 5360af53ff628602014ca8bcff74828ce3cda742
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
--HG--
extra : rebase_source : 30c6d8629c705b3cb1b3a186550720137d641e20
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
--HG--
extra : rebase_source : 7ab912ded4dee4e5104deebe3d5268017b63eb9b
- Lazily initialize file IO-specific stuff in ExtensionStorage.jsm,
and limit this work to the main process.
- Add local versions of the `storage.local.get` and `storage.local.set`
implementations that perform sanitization (without the change, values
are improperly serialized over IPC).
- Copied the `backgroundScript` test from xpcshell/test_ext_storage.js
to mochitest/test_ext_storage_content.html because they should behave
identical. Before this patch the test failed due to IPC serialization
issues, now the test passes.
Note that the old test also passes with the changes.
MozReview-Commit-ID: 8J8CCdwMACN
--HG--
extra : rebase_source : 7b8a490b79c09f69a10d4dc13ad23f8382b641d1
`context.principal` should be equal to the principal of the sandbox, so
that if a new sandbox is created using `Cu.Sandbox(principal)`, that
objects can be shared between the new sandbox and `context.cloneScope`
(= `context.sandbox`) without issues.
Without this change, using `context.jsonStringify` on an object from a
content script would trigger the following error:
> Error: Permission denied to access property "toJSON"
This scenario is covered by the test
toolkit/components/extensions/test/mochitest/test_ext_storage_content.html
in the next commit.
MozReview-Commit-ID: E4Jt8TDwNAZ
--HG--
extra : rebase_source : ada568f456efc31d6bcd0fa0b07ffe0358f30c1c
- 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
--HG--
extra : rebase_source : 8e1046d5c7b2ec18e6130ae92fe539f3c0e02706
E.g. browser.browserAction.enable(...).then(...) now works as expected.
Removed a Promise.resolve() because that is the default.
MozReview-Commit-ID: 4Shxtn0rjYH
--HG--
extra : rebase_source : 2f2516686c7d79094fac5ff1176c1c9310f1abe5
In the pageAction and browserAction schemas, several methods are
declared with `"async": true` but without a specified callback in the
`"parameters"` object, so callbacks are not allowed. However, when a
callback is proxied, the `ParentAPIManager` will mirror the call by
passing in an extra callback to the proxied API - and break.
This patch fixes the issue by removing uses of async:true. Also for
consistency between the browserAction and pageAction methods, the
methods that were not declared as async have also been marked as async.
MozReview-Commit-ID: JQqzmTUAotB
--HG--
extra : rebase_source : 62d1cbc4843dd6c792318337158e4311f8df94a4
When the background API move to a separate implementation,
then the schema APIs will be generated (and ChildAPIManager
will just delegate the implementation to the parent process).
The purpose of the test is to verify that nested namespaces and
null-feturn values work, so just use the base classes instead of a
concrete implementation for BaseContext / SchemaAPIManager instead of
setting up a full extension.
MozReview-Commit-ID: CB5s7Ae24zS
--HG--
extra : rebase_source : c9f50d84151b18323097e1a00d2eb3839a22f64d
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
--HG--
extra : rebase_source : 29725b686428c7c052838681f396ff877d19bb18
- 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
--HG--
extra : rebase_source : 1c569ab4733c8111960613fc210357960ae09e88
totalVideoFrameCount was previously incorrectly set to the number of demuxed
frames.
According to the current W3C specs [1], it should instead be the total number of
frames that have been presented, plus frames that have been discarded.
Also added a check that discarded<=total in mochitest.
[1] https://wicg.github.io/media-playback-quality/#concepts
MozReview-Commit-ID: Gnv1roM5n0A
--HG--
extra : rebase_source : 1f018612fbaf43867f5c92e59d62d718a3b08535
