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
