Add permission to the active tab on mousedown in ext-browserAction.js
MozReview-Commit-ID: H0oXQElppo7
--HG--
extra : rebase_source : 09ac61c479b57cb487bd81855dd9acae27537f39
extra : source : 935c49da3488b4270cf45447451d6bb0abe3f369
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
When tabs.onUpdated is called before the promise of windows.create
resolves, the test fails.
This test failure was observed on almost every try run with non-e10s,
and sometimes (rarely) with e10s.
MozReview-Commit-ID: 3znCP1uAUSB
--HG--
extra : rebase_source : ec150b83f85a50f75eda2a0e41f3a60611625046
The test/browser/browser_ext_windows_update.js test fails on Linux.
The window ID is not expected to change, add assertion for it to
eliminate causes for test failures.
Ultimately, it turns out that the test failure is caused by a defect
in the implementation, not the test itself, see bugzil.la/1307759
MozReview-Commit-ID: Lo8IIvcfYQ2
--HG--
extra : rebase_source : 12ffc9c2d545723b012b6c5dcf216e7ef34e1790
Reload about:blank tab after opening it and registering the
`tabs.onUpdated` event. This is needed because about:blank loads very
fast, before the callback of `tabs.create` is invoked. This effect is
amplified by the fact that the APIs are now proxied.
MozReview-Commit-ID: DgPtIqHSUDx
--HG--
extra : rebase_source : afe6ec984bed06f47c24e39fee6fa7c757c3dde3
contextMenusInternal.onClicked is already inlined in context_menus.json.
It should be removed because otherwise the
`browser.contextMenusInternal.onClicked` API would be generated.
MozReview-Commit-ID: LAKd2IGM5GU
--HG--
extra : rebase_source : 60668c2ef75661eefe21ce3135a2b7d7d320cb7b
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
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
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
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
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
