The path service was created to allow us to track resources that were part of
legacy add-ons, and to map URIs ponting to those resources to add-on IDs, so
that we could apply special behavior to them.
We have better ways to track resources belonging to WebExtensions, so this
code does not benefit them in any significant way.
The only remaining legacy extensions are system add-ons, which we control, and
do not need the path service in order to track.
MozReview-Commit-ID: BKXkcaM7jJx
As described in the bug, this is intended as a temporary solution to
enable some experiments. If this becomes a real feature, UX will
put some thought into a better startup experience.
MozReview-Commit-ID: 4DGMHj29M3e
This patch additionally removes the check where if AddonManagerPrivate.backgroundUpdateTimerHandler does not call AddonManagerInternal.backgroundUpdateCheck if updates to all addons are disabled. The check is redundant as AddonManagerInternal.backgroundUpdateCheck makes those same checks.
MozReview-Commit-ID: FxS8127JYkn
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
When we detect a new add-on during a directory scan, we initially add a
skeleton XPIStates entry for it, and rely on the database reconciliation to
fill in the details later in startup. In the case of extensions with invalid
install.rdf files, though, this doesn't happen, and the entry remains as we
initially created it. Since those entries are currently marked enabled by
default, and the XPIStates entries determine what non-bootstrapped chrome
manifests we load at startup, that leads to us mistakenly loading resources
that we shouldn't.
This change marks newly-detected entries disabled by default, and leaves it to
later startup stages to enable them if necessary. We still leave the XPIStates
entry in place, since removing it would cause us to rebuild the database on
every subsequent startup, when we re-detect it.
MozReview-Commit-ID: AvBmj79Ro2W
getActiveAddons can either return partial or full data for use by the Telemetry
Environment. This is just a spike that communicates that difference out of
XPIProvider and into the Environment so we know whether the DB has been loaded.
MozReview-Commit-ID: 4Y5mq5aM6uu
Changes to Promise tests designed to test .then(null) have been reverted, and the browser/extensions directory was excluded because the projects it contains have a separate process for accepting changes.
MozReview-Commit-ID: 1buqgX1EP4P
Add AddonManager.getActiveAddons() which can be called during
startup to get a limited amount of information about active addons
without forcing an unwated read of the extensions database.
MozReview-Commit-ID: Fj6z5eYgYYC
The background page do not need to use the AddonManager to set its preferred debugging global
anymore (and it would not be able to use it from the extension child process).
MozReview-Commit-ID: 2IAxvCjDKvl
The background page do not need to use the AddonManager to set its preferred debugging global
anymore (and it would not be able to use it from the extension child process).
MozReview-Commit-ID: 2IAxvCjDKvl
I'm adding a helper function mozILocaleService::GetRequestedLocale to simplify
most of the callsites that are looking for the first of the requested locales.
In most cases, I'm just matching the behavior of the code with reusing
LocaleService API instead of direct manipulation on the prefs.
That includes how I handle error case scenarios.
In case of sdk/l10n/locale.js I am reusing LocaleService heuristics over
the custom one from the file since the ones in LocaleService are just
more correct and unified accross the whole platform.
In case of FallbackEncoding I have to turn it into a nsIObserver to listen
to intl:requested-locales-changed.
MozReview-Commit-ID: 7rOr2CovLK