Manually-implemented QueryInterface functions don't benefit from the
MozQueryInterface optimizaions, and a lot of them are in hot code, and
implement a large number of interfaces.
MozReview-Commit-ID: 8OzglraowZt
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 {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
This ended up being a bigger change than I had hoped for but
it updates the WebAPITask helper in amWebAPI.js so that errors
returned from the parent process are immediately wrapped into
Error objects from the content page. In this way, programming
errors or other internal errors don't leak out to mozAddonManager
users.
The way the previous code managed window references using "this"
was already a bit fussy, this patch only makes it worse. But I
think this basic logical structure here is right and since this
bug is responsible for widespread breakage, I'd like to get this
checked in and then clean it up in a follow-up.
MozReview-Commit-ID: 98PgbWKsHIN
This adds a bunch of structure supporting a promise-based API on the
AddonManager object that is exposed to webpages and adds the first example,
getAddonByID.
MozReview-Commit-ID: CCEFl4R1o81
Since we want to add a few APIs that AMO can use to query and manipulate the
user's add-ons we want to expose a custom API. This implements the webidl and
a stub implementation in JavaScript. We use the webidl functions for controlling
access to the API, only the AMO production domains (and some test domains when
testing is enabled) can access it and only when retrieved securely and not in
an inner frame of a page that shouldn't have the API.
MozReview-Commit-ID: 3HUUrduuHwf