I decided not to use aria-disabled directly because we currently don't
cache it in the parent, and I don't think the benefit would be great
enough.
Differential Revision: https://phabricator.services.mozilla.com/D250357
This reverts commit d4794289e7.
Revert "Bug 1899960 - P1: Don't cache implicit states. r=Jamie"
This reverts commit dd5d2cd561.
Revert "Bug 1967813 - Check menu's frame IsOpen to determine if menu is active. r=morgan"
This reverts commit 2d6a0f17e3.
I decided not to use aria-disabled directly because we currently don't
cache it in the parent, and I don't think the benefit would be great
enough.
Differential Revision: https://phabricator.services.mozilla.com/D250357
This revision modifies AppendMutationEventData such that it can actually send
mutation event batches over IPC. Previously, we were waiting for massive batches
of mutation events before sending, which leaves the parent process with little
to do until it receives one big message. While more efficient from the content
and parent process' perspective individually, the overall load time of pages
suffered from having such large batch sizes sent after all mutation events have
been calculated. The overall page load time benefits from having both content
and parent processes execute accessibility-related tree building code in
parallel, even though there is some inefficiency associated with interrupting
tree-building to serialize, send, and receive an IPC message more often.
After performance testing, we've found that we can accumulate Accessibles in
events up to a reasonable max before sending the batch. From testing, 1000 looks
like a good number. This gives us big performance wins for loading pages, while
maintaining our performance in fast-mutating pages.
Differential Revision: https://phabricator.services.mozilla.com/D235515
The way the code was written it would expect a uniform overflow style
for both x and y. We need to make sure to handle each axis separately.
Differential Revision: https://phabricator.services.mozilla.com/D231997
A document's body element can lose its scroll frame if the root element (eg. <html>) is restyled to overflow scroll/auto. In that case we will not get any useful notifications for the body element except for a reframe to a non-scrolling frame.
The place where we see this as a problem is in hit testing because
accessibles get erroneously clipped out because of stale scroll
positions.
Differential Revision: https://phabricator.services.mozilla.com/D231821
This revision modifies the way that ProcessMutationEvents works. Rather than
firing mutation events immediately, it instead causes them to be queued on
DocAccessibleChild via HandleAccEvent. The code then fires the events in batches
with a new IPC method, SendMutationEvents. The net effect of this change is a
significant reduction in pressure on the IPC system, in favor of fewer, larger
messages. For pages that generate many mutation events often, this represents a
big win for performance. Without this, the IPC queue can get backed up, failing
to keep up with the amount of accessibility IPC messages as they flood in.
The method of batching is carefully written to maximize the amount of
accessibles that can be touched in a mutation event batch without going
over the IPC message size limit. This revision does not implement size
tracking, but does make a reasonable approximation. With these changes,
heterogenous mutation event types can sit together in batches, including
sub-batches of show events. A side effect of this change is that initial
page load is further amalgamated; multiple document children that
produce separate calls to InsertIntoIpcTree now use this queueing
mechanism and can have their show events sent together.
Some messages may fire differently from their former ordering with this change,
particularly EVENT_MENUPOPUP_END for content processes. However, that event
appears to have been fired out of order with the existing code, meaning
that this change represents a fix to that ordering issue as well.
Finally, this revision makes a slight modification to an Android test
for clarity and correctness. I discovered this issue while debugging
event ordering and realized it was valuable to fix.
Differential Revision: https://phabricator.services.mozilla.com/D229842
Windows screen readers must call IAccessible2::attributes for every show or text inserted event in order to determine whether the inserted content is within a live region, since this is only exposed via an object attribute.
These attributes include group position attributes: posinset, setsize and level.
When thousands of items are being inserted into a container such as a list, these queries can become expensive, even despite some of the information being cached.
For IA2, including group position attributes is redundant in most cases, since there is a dedicated IAccessible2::groupPosition property for this purpose.
Similarly, Mac code sometimes calls Accessible::Attributes, but it never uses the group position attributes, since it can use Accessible::GroupPosition() instead.
That said, I don't know of a case where this is actually a problem in practice on mac.
To address this:
1. No longer return group position attributes in Accessible::Attributes.
2. XPCOM clients, including tests and DevTools, still depend on these attributes, so update xpcAccessible::GetAttributes to include them.
3. ATK has no dedicated group position query, so update the ATK code to include these attributes too.
4. On Android, we could call GroupPosition directly, but it's easier to just pass AccAttributes to AccessibleWrap::GetRoleDescription, so include these attributes there too.
5. As an exception, IA2 requires the level attribute for headings, so include them just for roles::HEADING.
Differential Revision: https://phabricator.services.mozilla.com/D231653
The iterator uses both explicitly set element attributes and content attributes
with IDs to iterate over all associated elements
Differential Revision: https://phabricator.services.mozilla.com/D215688
The iterator uses both explicitly set element attributes and content attributes
with IDs to iterate over all associated elements
Differential Revision: https://phabricator.services.mozilla.com/D215688
Previously, we used the primary frame.
This was problematic for image map areas because they don't have a frame, so we were always using the top left of the entire image.
RelativeBounds has been overridden for image map areas to correctly calculate coordinates.
Therefore, rather than special casing image map areas again, use RelativeBounds in DispatchClickEvent.
Differential Revision: https://phabricator.services.mozilla.com/D229300
This just improves readability.
There should be no functional change except that I gave this Runnable a proper name while I was at it.
Differential Revision: https://phabricator.services.mozilla.com/D229298
We never set this argument to anything other than the default, which meant it always used the LocalAccessible's mContent.
This makes the argument unnecessary and potentially confusing in an area which is already a bit difficult to follow, so just remove it.
There should be no functional change.
Differential Revision: https://phabricator.services.mozilla.com/D229297
The iterator uses both explicitly set element attributes and content attributes
with IDs to iterate over all associated elements
Differential Revision: https://phabricator.services.mozilla.com/D215688
This revision adds a null check on mBounds in BundleFieldsForCache, in order to
avoid crashing in release when mBounds is empty.
Differential Revision: https://phabricator.services.mozilla.com/D225273
