We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
Consider the following sequence of events:
* We do an l10n mutation -> mBlockingLoad=true, mPendingMutations.Size() = 1
* That flush triggers a promise -> mBlockingLoad=true, mPendingMutations.Size() = 0, mPendingPromises=1
* Another mutation happens -> mBlockingLoad=true, mPendingMutations.Size() = 1, mPendingPromises = 1
* The promise resolves -> mBlockingLoad=true, mPendingMutations.Size() = 1, mPendingPromises=0
Key part there is that the second mutation didn't post a task to flush,
so we rely on the refresh driver (which is not reliable on Wayland as
described in the comment).
Instead, we need to track the pending flush separately from the blocking
load.
Differential Revision: https://phabricator.services.mozilla.com/D174624
Otherwise we have some promises that may never resolve. This causes
issues in
toolkit/content/tests/widgets/test_videocontrols_jsdisabled.html with
the previous patch, for example.
Differential Revision: https://phabricator.services.mozilla.com/D171564
`l10n.setAttributes` should work atomically, so a failure in handling l10n args does not allow for the l10n id be set by itself.
Differential Revision: https://phabricator.services.mozilla.com/D167147
Deletion of mutation observers from a list resulted in O(n^2) behavior and could lead to massive freezes.
This is resolved by using a LinkedList instead, reducing complexity to O(n).
A safely iterable doubly linked list was implemented based on `mozilla::DoublyLinkedList`,
allowing to insert and remove elements while iterating the list.
Due to the nature of `mozilla::DoublyLinkedList`, every Mutation Observer now inherits `mozilla::DoublyLinkedListElement<T>`.
This implies that a Mutation Observer can only be part of one DoublyLinkedList.
This conflicts with some Mutation Observers, which are being added to multiple `nsINode`s.
To continue supporting this, new MutationObserver base classes `nsMultiMutationObserver` and `nsStubMultiMutationObserver` are introduced,
which create `MutationObserverWrapper` objects each time they are added to a `nsINode`.
The wrapper objects forward every call to the actual observer.
Differential Revision: https://phabricator.services.mozilla.com/D157031
`Aria-valuetext` attribute is expected to be mutated with each change of user's input, thus it does not have to be listed as localizable attribute.
Also, this approach removes pre-selected value from the DOM on init of a component like a spinbutton, preventing users of assistive technology from accessing human-readable value that was pre-selected and is present on-screen.
Updating a patch to ensure [the fix for bug 1779625](https://bugzilla.mozilla.org/show_bug.cgi?id=1779625) is still working after the change per discussion in Bugzilla.
Differential Revision: https://phabricator.services.mozilla.com/D142371
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
- Updates Gecko's Fluent class to use the new ResourceId type,
which can be either optional or required regarding a particular resource.
- Adds JS tests verifying the new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D133579
