This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
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
In order to clean up sync IO within our profile migrators, we
need to have async interfaces for those parts which are currently
doing sync IO. This converts the sync interfaces and adjusts most
of the call sites (migration.js call site changes are addressed
in a separate patch to break it out a bit).
MozReview-Commit-ID: 2Kcrxco4iYr
In cases, where the caller is looking for the locale to be used for JS Intl API,
we can now replace it with `undefined` which causes JS Intl API to use the default
locale which since bug 1346674 is resolved to the app locale.
This allows us to remove a lot of calls for the app locale.
The remaining ones are split between `AsBCP47` and `AsLangTag`.
Here, the `AsLangTag` is used, as described in the API docs, for cases where
the language string is used for localization purposes, such as language negotaition
matching to our language resources etc.
`AsBCP47` is used when the returned value is handed over to ICU API.
MozReview-Commit-ID: DzmFEUvMq3N
In cases, where the caller is looking for the locale to be used for JS Intl API,
we can now replace it with `undefined` which causes JS Intl API to use the default
locale which since bug 1346674 is resolved to the app locale.
This allows us to remove a lot of calls for the app locale.
The remaining ones are split between `AsBCP47` and `AsLangTag`.
Here, the `AsLangTag` is used, as described in the API docs, for cases where
the language string is used for localization purposes, such as language negotaition
matching to our language resources etc.
`AsBCP47` is used when the returned value is handed over to ICU API.
MozReview-Commit-ID: DzmFEUvMq3N
The automated test verifies that we remove the notification bars immediately.
Unfortunately, I couldn't think of a way to verify we won't allow reshowing the notification bar while an undo is ongoing,
because for that to happen I'd need to get one to show while an undo is ongoing, which isn't reliably possible in an
automated test.
MozReview-Commit-ID: EYHNIPEaOOo
As noted on the bug, because we call getMigratorKeyForDefaultBrowser() multiple times,
its value no longer reflects the (deleted) registry key for subsequent calls.
While we can fix this for the automigrate case by just passing the default we determined a few
lines earlier (and that seems worth doing to avoid busywork), there are 2 small problems
with this:
1) if the default browser has no data, `migratorKey` won't be set, and so we'll call the same
method again anyway, and the message reported in the error console will be that we can't
migrate from Firefox, when the real problem is that we can't migrate from the original
default browser.
2) there are other callers besides AutoMigrate. Specifically, migration.js also calls this
method.
To deal with these, I've fixed getMigratorKeyForDefaultBrowser() to return the same
registry-based value for its lifetime if we hit the 'the default is firefox, go look for an
earlier default' case.
I've verified that either the s/aMigratorKey/migratorKey/ or the change to
getMigratorKeyForDefaultBrowser() are sufficient to make this work properly in the
automigration case.
While I was here, I also updated one of the error messages to be more explicit.
MozReview-Commit-ID: GeUNTfScMMB