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
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
Nothing in mozilla-central uses the NS_APP_BOOKMARKS_50_FILE/BMarks key except
tests. It's also not been very useful since the switch to places in ... Firefox
3? so even if addons use it, it's not doing them much good.
BookmarkHTMLUtils.defaultPath returns the same thing anyways for those that
really do insist on getting the equivalent thing (but I'd argue
BookmarkHTMLUtils.defaultPath, as well as the browser.bookmarks.file pref could
just go away as well).
Seamonkey does use NS_APP_BOOKMARKS_50_FILE/BMarks, but they really only need
the #define, which they can add in their source.
