This required changing the RemoteAccessible implementations to return Relation instead of an array of RemoteAccessible.
Platform implementations have been updated to use the unified method where appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D152959
This is basically RemoteExplicitHeadersIterator with naming generalised.
Support has been added for transferring ownership of the array into the iterator, which will be needed when the cache is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D152958
Previously, Relation::Next returned a LocalAccessible.
Now, it returns an Accessible so that it can support RemoteAccessible as well.
Relation::LocalNext has been added as a convenience to return a LocalAccessible when the caller is certain that only LocalAccessible is relevant.
Callers have either been updated to use LocalNext or to handle an Accessible returned from Next.
ia2AccessibleRelation now holds an array of MsaaAccessible, as we need to hold references and we can't hold references to RemoteAccessible.
Differential Revision: https://phabricator.services.mozilla.com/D152957
1. When we receive text for a text leaf, even for an initial cache push. Previously, we only did this for a cache update. However, a client call could arrive between the tree push and the initial cache push, resulting in an incorrect offsets cache.
2. When an Accessible is moved. Previously, if a client queried an Accessible while it was being moved or if an Accessible had children before the move but no children after, the cached HyperText offsets could be invalid.
Differential Revision: https://phabricator.services.mozilla.com/D153139
This is possible if a client query arrives between the two IPDL calls for the tree and the cache.
This might even happen for an ancestor in the case of an OOP iframe, where IPDL calls for the two documents might be interspersed.
Differential Revision: https://phabricator.services.mozilla.com/D153134
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
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519