These are fixes for issues noticed with NumberFormatterSkeleton while testing
this code in SpiderMonkey against the full set of intl tests there. I've added
minimal test cases for the issues encountered as part of this patch.
Differential Revision: https://phabricator.services.mozilla.com/D112240
This adds an initial version of NumberFormat that is suitable for use by
Fluent.
The options formatting code is taken from SpiderMonkey and modified to use the
standard c++ library rather than SpiderMonkey specific code. The code
generated MeasureUnitGenerated.h is duplicated here temporarily. Once we can
move SpiderMonkey to using this code, we can update the code generation to
avoid this duplication.
Some simple gtests have been written to make development easier. Full test
coverage is not a goal here, as this code will eventually be covered by running
test262 in SpiderMonkey.
Differential Revision: https://phabricator.services.mozilla.com/D107223
This adds an initial version of NumberFormat that is suitable for use by
Fluent.
The options formatting code is taken from SpiderMonkey and modified to use the
standard c++ library rather than SpiderMonkey specific code. The code
generated MeasureUnitGenerated.h is duplicated here temporarily. Once we can
move SpiderMonkey to using this code, we can update the code generation to
avoid this duplication.
Some simple gtests have been written to make development easier. Full test
coverage is not a goal here, as this code will eventually be covered by running
test262 in SpiderMonkey.
Differential Revision: https://phabricator.services.mozilla.com/D107223
Due to an unfortunate typo I made in base_chars.py, I thought that there
were no mappings we care about outside of the basic multilingual plane.
This patch adds back the non-BMP mappings that we do care about.
Differential Revision: https://phabricator.services.mozilla.com/D107404
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
GetValue is going to be removed in a subsequent patch. It is no longer needed,
because it can be replaced by functions already provided by nsBaseHashtable,
in particular Lookup and Contains.
Also, its name was confusing, since it specifically returns a pointer that
allows and is intended for modifying the entry within the hashtable, rather
than returning by-value. According to the naming rules to be set on
nsBaseHashtable, it would also needed to be renamed to "Lookup*. Removing
its uses saves this effort.
Differential Revision: https://phabricator.services.mozilla.com/D105476
This patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
This patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
These services had their name added to components.conf:
* GfxInfo
* ThirdPartyUtil
* History
* HttpActivityDistributor
* UUIDGenerator
* ServiceWorkerManager
* PermissionManager
These services were added to componenets.conf under a different name:
* DirectoryService => Directory
* IOService => IO
* StringBundleService => StringBundle
* CacheStorageService => CacheStorage
* StreamTransportService => StreamTransport
* SocketTransportService => SocketTransport
These services weren't migrated to components.conf because only Rust
code uses them:
* RemoteAgent
* XULRuntime
* PrefService
These services weren't migrated to components.conf because they're unused:
* ToolkitChromeRegistry (used as ChromeRegistry)
* XULChromeRegistry (used as ChromeRegistry)
* Bits (completely unused)
These services were already available in components.conf but are still
used by rust code:
* URIFixup
These services weren't migrated because they will be handled in
subsequent patchsets:
* ObserverService
For the record, the following Services are being used by Rust code
and must remain until a Rust version of Components.h is written:
* RemoteAgent
* XULRuntime
* PrefService
* URIFixup
* ObserverService
* DirectoryService
* ThirdPartyUtil
Also the cocoa GfxInfo service was changed to use components.conf instead
of registering it at runtime, as all the other widgets were already doing
it this way.
Differential Revision: https://phabricator.services.mozilla.com/D105521
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