These macros will produce better outputs when they fail than these existing
patterns using `ENSURE_TRUE(NS_SUCCEEDED(...))` or similar, so this is a bulk
rewrite of existing tests to use them.
It should also help with discoverability when people base their tests off of
other existing tests.
Differential Revision: https://phabricator.services.mozilla.com/D157214
As part of installing the lang pack, add the negotiated language as string args and convert to raw if it wants to use the lang pack.
Differential Revision: https://phabricator.services.mozilla.com/D155021
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
The fallback locale is not guaranteed to have all of the strings for
non-fluent files, even if it is one of the available locales. This patch
shares the logic with about:preferences for getting the available
locales.
Differential Revision: https://phabricator.services.mozilla.com/D143910
I considered removing this class initially, but it's actually a pretty
useful abstraction over the DateTimeFormat interface when used
specifically with Gecko. It applies the OS preferences and provides some
caching behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131671
I considered removing this class initially, but it's actually a pretty
useful abstraction over the DateTimeFormat interface when used
specifically with Gecko. It applies the OS preferences and provides some
caching behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131671
There is also a mozilla::intl::Locale in intl/locale/MozLocale.h. This naming
collision was causing crashes in debug builds where the wrong destructor ended
up being called. This patch renames the intl/locale/MozLocale.h class to
MozLocale.
I've filed Bug 1736017 to move callers of the MozLocale version to the
unified intl/components/Locale version.
Differential Revision: https://phabricator.services.mozilla.com/D128593
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
As is the case with GTK, Android provides an OS override to display times in
AM/PM or 24 hour format. This moves the code for rewriting skeletons from the
GTK specific code to OSPreferences, and calls it from the Android OSPreferences
implementation.
This was tested manually by visiting the file:/// uri. I don't believe this is
feasible to test from automation, as it would require changing Android OS settings
from within our test code.
Differential Revision: https://phabricator.services.mozilla.com/D101641
As is the case with GTK, Android provides an OS override to display times in
AM/PM or 24 hour format. This moves the code for rewriting skeletons from the
GTK specific code to OSPreferences, and calls it from the Android OSPreferences
implementation.
This was tested manually by visiting the file:/// uri. I don't believe this is
feasible to test from automation, as it would require changing Android OS settings
from within our test code.
Differential Revision: https://phabricator.services.mozilla.com/D101641
This switches over to using nsIGSettingsService. This makes the gtest results
on gtk based systems depend on the current OS settings, so the test expectations
are adjusted to accept both AM/PM and 24h settings.
Differential Revision: https://phabricator.services.mozilla.com/D101362
This also removes pref overrides from methods like LocaleService::IsLocaleRTL or
IntlService.getLocaleInfo, because it doesn't really make sense to override the
result of checking an arbitrary locale, the relevant use case is overriding the
result for the current app locale.
Removal of the intl.uidirection pref completely will be done in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D96235
