This change allows GeckoView embedders to respond to
`runtime.sendNativeMessage` and `runtime.connectNative` sent from
WebExtensions.
These APIs are available behind the new privileged-only permission
`geckoViewAddons` and are used by GeckoView apps to communicate between content
and the app.
Depends On D22621
Differential Revision: https://phabricator.services.mozilla.com/D22622
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
This simplifies things all around, and gets rid of one more unnecessary
component registration.
--HG--
rename : toolkit/components/extensions/extension-process-script.js => toolkit/components/extensions/ExtensionProcessScript.jsm
extra : rebase_source : 7ceb6ada0730f8241bbd5ddbd889a320da22b1b1
The performance counter is now also used in the children, and
the ParentAPIManager.retrievePerformanceCounters() can be used
to aggregate all counters into a promise.
Differential Revision: https://phabricator.services.mozilla.com/D5399
--HG--
extra : moz-landing-system : lando
This schema was inherited from Chromium (where it was an internal
implementation detail. This schema only defined the OnClickData
type, but was never actively used by our WebExtensions framework,
because menus.json already defines the OnClickData type.
Note: menus_internal.json specified the "menusInternal" namespace
which we do indeed implement in parent/ext-menus.js (and use in
child/ext-menus.js). However, none of the methods that we add to
menusInternal are actually defined in the schema.
This use of menusInternal was introduced in part 2 of bug 1333403 and
works without problems because the API schemas are not being used to
validate APIs as of part 2 of bug 1315575.
The only significance of "menusInternal" is that the namespace is
defined in browser/components/extensions/ext-browser.json,
implemented in browser/components/extensions/parent/ext-menus.js
and used by browser/components/extensions/child/ext-menus.js
MozReview-Commit-ID: 2ACpn595QZQ
--HG--
extra : rebase_source : f3e16486168dfb0baa56dda7ccf591855bbe90bb
At its inception, ExtensionChild.jsm was meant to be used for the
extension child process. Over time, this intent was not consistently
followed, and in bug 1317697 this was fixed by splitting some logic
in ExtensionChild.jsm off to ExtensionPageChild.jsm.
Henceforth ExtensionChild.jsm handles logic that is common to all
content processes, including web content and extension logic.
Updated the comment at the top of the file to match this reality.
MozReview-Commit-ID: 3cAd0FPj6Vz
--HG--
extra : rebase_source : 21bfd642460dd72159af120a9f81cbc7ae0b0572
This "scripts" getter started to become unused in:
https://hg.mozilla.org/mozilla-central/rev/1267d47eca93
The "extension" in the "extension.scripts" above was changed
from "BrowserExtensionContent" to "StubExtension".
(and this "StubExtension" does not exist in the current code base any
more, as it has been replaced with "WebExtensionPolicy" - see the bug).
MozReview-Commit-ID: HkNhy4QOB15
--HG--
extra : rebase_source : bf64d00cb41281ebc4009eb9c9d8245b3438114d
initialProcessData has the unfortunate side-effect of sending an entire copy
of all of its data to all content processes, and eagerly decoding it. For the
extension framework, this means that we wind up loading an entire copy of all
of our schema data, and of every extension's manifest and locale data, into
every process, even if we'll never need it.
The sharedData helper allows us to store an encoded copy of that data in a
shared memory region, and clone it into the current process only when we need
it, which can be a significant savings. For screenshots alone, it saves about
15K on locale and manifest data per content process, plus the size we save on
not copying schema data.
MozReview-Commit-ID: KkIOoLsBd99
--HG--
extra : rebase_source : 21cb433e8897a3d33943ebbd3d788d8d54e0844b
extra : source : 8074c985095c9951171311dac840684b915a57f6
initialProcessData has the unfortunate side-effect of sending an entire copy
of all of its data to all content processes, and eagerly decoding it. For the
extension framework, this means that we wind up loading an entire copy of all
of our schema data, and of every extension's manifest and locale data, into
every process, even if we'll never need it.
The sharedData helper allows us to store an encoded copy of that data in a
shared memory region, and clone it into the current process only when we need
it, which can be a significant savings. For screenshots alone, it saves about
15K on locale and manifest data per content process, plus the size we save on
not copying schema data.
MozReview-Commit-ID: KkIOoLsBd99
--HG--
extra : rebase_source : 294a3fb2f045bef044cfbebe6fc6f1b1ee2be91b
The schema handling for this is currently a bit ugly, for the sake of
simplifying uplift. In the figure, we should find a way to change the schema
pattern matching based on whether or not the extension is privileged.
MozReview-Commit-ID: CU9WR2Ika6k
--HG--
extra : rebase_source : 28e1c43cf0f0efc01b40757e4e65c4ac5d882258
- Previously, if a port is disconnected by the other end, then memory
would be leaked to `ProxyMessenger.ports` in ExtensionParent.jsm.
To fix this, the port descriptor is now saved separately, keyed by
port ID instead of message manager.
- Previously, when a message manager was disconnected (e.g. window
closed/tab crashed), the port is disconnected only if the port was
created from that page.
This patch adds bookkeeping to keep track of the message managers at
both the sender and receiver's side, so that the port is always
disconnected when the other side goes away.
- The new test browser_ext_port_disconnect_on_crash.js checks whether
the ports are disconnected as expected. Previously, the subtest
connect_from_tab_to_bg_and_crash_tab failed because of the previous
point.
- Although not as deterministic as the crash test, the new
browser_ext_port_disconnect_on_window_close.js reproduces the original
test failure and serves as a regression test for the bug.
- Previously, the data structure in ProxyMessenger.ports contained
the original `sender` and `recipient`. For the purpose of sending
port disconnection messages, these are not necessary and therefore
they have been removed.
- Fix incorrect JSDoc (type of portId is number, not string)
MozReview-Commit-ID: BoaKRVAUKuq
As we add more behaviors to EventManager, the signature of the constructor
is going to get really clumsy. Head that off by converting it to take a
general parameters object.
This introduces a compatibility problem for existing webextension experiments,
put in a backward-compatibility shim for now.
MozReview-Commit-ID: 72QDfiwRm5j
--HG--
extra : rebase_source : 31c3fd561f373a5d75c4336de830aa5a2abfe797
We currently report a useful location in error reports when extensions fail to
resolve a promise or call a response callback, but in some slightly
less-than-ideal ways. We currently generate a complete stack and parse its
string value (which is expensive), and then report the caller location as part
of the message, rather than as the error's location and stack.
This patch changes that behavior to store a single SavedStack frame, and to
properly report that as the location of the error.
MozReview-Commit-ID: Jmtf4C1O6pW
--HG--
extra : rebase_source : a47795947e1c93934ec3ced29dd6d345937d443e
Currently, when we create an error object at the end of an aysnc operation, we
only get a useful caller location if async stacks are enabled.
This patch changes our behavior to use the saved caller location we've already
stored when creating an Error object based on a plain string message.
MozReview-Commit-ID: DDO0lAUHYRO
--HG--
extra : rebase_source : 995ea3c6de26b616a6cef483b271e222bb2aaf6e
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <