This just redirects to the local TableAccessible methods.
This allows us to test selection in our mochitests.
As far as I know, real clients don't actually use these methods , so they haven't been implemented for cached RemoteAccessibles yet.
Differential Revision: https://phabricator.services.mozilla.com/D141215
Headers are associated using the headers DOM attribute, which is a list of DOM node ids.
For the cache, we send and store these as Accessible ids.
Differential Revision: https://phabricator.services.mozilla.com/D141212
We need to be able to iterate through explicitly associated headers for both local and remote Accessibles.
AccIterable will serve nicely as a base class, but it needs to support the Accessible base class to do that.
Differential Revision: https://phabricator.services.mozilla.com/D141210
This is a completely new table implementation which can work with the cache.
We lazily create a cache data structure only when table information is requested by a client, looping through the entire table and calculating all the information we need (counts, coordinates, implicit headers, etc.).
Whenever the cache is invalidated due to a mutation of the table structure, we throw away the entire cache, rebuilding it next time the client requests information.
Differential Revision: https://phabricator.services.mozilla.com/D141206
There is no base class for local (DocAccessible) and remote (DocAccessibleParent) documents, so this adds nsAccUtils::GetAccessibleByID.
Differential Revision: https://phabricator.services.mozilla.com/D141207
Previously, when we were about to add text from a text node, we looked at the parent to determine if it was a block element and added space based on that.
This caused problems if there were multiple text nodes inside a block because we ended up adding space between those text nodes, even if there was no intervening block.
Instead, since we're walking the tree, we now add space whenever we encounter a block, both before and after its descendants.
If there are multiple adjacent blocks, this does mean we append multiple spaces, but we compress space befor returning to the caller anyway.
This fixes highlights in address bar suggestions being separated from the rest of the suggestion.
Differential Revision: https://phabricator.services.mozilla.com/D141722
Previously, when we were about to add text from a text node, we looked at the parent to determine if it was a block element and added space based on that.
This caused problems if there were multiple text nodes inside a block because we ended up adding space between those text nodes, even if there was no intervening block.
Instead, since we're walking the tree, we now add space whenever we encounter a block, both before and after its descendants.
If there are multiple adjacent blocks, this does mean we append multiple spaces, but we compress space befor returning to the caller anyway.
This fixes highlights in address bar suggestions being separated from the rest of the suggestion.
Differential Revision: https://phabricator.services.mozilla.com/D141722
This just redirects to the local TableAccessible methods.
This allows us to test selection in our mochitests.
As far as I know, real clients don't actually use these methods , so they haven't been implemented for cached RemoteAccessibles yet.
Differential Revision: https://phabricator.services.mozilla.com/D141215
Headers are associated using the headers DOM attribute, which is a list of DOM node ids.
For the cache, we send and store these as Accessible ids.
Differential Revision: https://phabricator.services.mozilla.com/D141212
We need to be able to iterate through explicitly associated headers for both local and remote Accessibles.
AccIterable will serve nicely as a base class, but it needs to support the Accessible base class to do that.
Differential Revision: https://phabricator.services.mozilla.com/D141210
This is a completely new table implementation which can work with the cache.
We lazily create a cache data structure only when table information is requested by a client, looping through the entire table and calculating all the information we need (counts, coordinates, implicit headers, etc.).
Whenever the cache is invalidated due to a mutation of the table structure, we throw away the entire cache, rebuilding it next time the client requests information.
Differential Revision: https://phabricator.services.mozilla.com/D141206
There is no base class for local (DocAccessible) and remote (DocAccessibleParent) documents, so this adds nsAccUtils::GetAccessibleByID.
Differential Revision: https://phabricator.services.mozilla.com/D141207
There are several valid reasons for a HyperTextAccessible to have no frame.
As well as removing the assertion, document the (known) cases where GetFrame() might return null.
Also, document why we create a DocAccessible and call DoInitialUpdate despite a null root frame on its PresShell.
Differential Revision: https://phabricator.services.mozilla.com/D139908
There was already a code path to handle siblings, but this only applied if the boundary child at the range's start/end (often a text leaf) was a sibling of aContainer.
It didn't apply if aContainer was a direct sibling of the range's start/end container.
To fix this, don't restrict the code which handles the case where aContainer does not contain the start/end boundary.
This should always fail to crop, regardless of the ancestry.
Differential Revision: https://phabricator.services.mozilla.com/D139351
Even though we'd ideally be using TextLeafRange for new things, TextRange is still needed by our selection events (which still use HyperText offsets) and IA2/ATK clients which depend on HyperText offsets.
Thus, we need TextRange to support RemoteAccessible.
Although the start and end containers are HyperTextAccessibles, I chose to store Accessible rather than HyperTextAccessibleBase because HyperTextAccessibleBase doesn't inherit from Accessible and having an Accessible is easier.
XPCOM needs to hold a reference to any state objects.
Because we can't hold a reference to an Accessible (due to RemoteAccessible), xpcAccessibleTextRange holds references to xpcAccessibleHyperText instead.
Differential Revision: https://phabricator.services.mozilla.com/D139341
This class needs to be updated to support base Accessible and it doesn't make sense to port methods that can never be used.
Also, any new functionality (e.g. needed for the UIA text pattern) should now be implemented using TextLeafPoint/Range, not TextRange.
Differential Revision: https://phabricator.services.mozilla.com/D139340
This also adds Accessible::DisplayStyle, as we sometimes want to be able to get the display style without fetching all the Attributes.
Differential Revision: https://phabricator.services.mozilla.com/D138629
The XPCOM interface and AccVCChangeEvent still only support LocalAccessible.
These will need to be updated/refactored in the future.
Differential Revision: https://phabricator.services.mozilla.com/D138247
The XPCOM interface and AccVCChangeEvent still only support LocalAccessible.
These will need to be updated/refactored in the future.
Differential Revision: https://phabricator.services.mozilla.com/D138247
BOUNDARY_WORD_END is implemented using BOUNDARY_WORD_START and adjusting for spaces, which are word end boundaries.
This is arguably less efficient than it could be, since we will walk over space and then reverse course to compensate.
However, the alternative would mean keeping two slightly different versions of the word boundary check code in sync, plus compensating for the fact that a word often ends before a line start while still supporting words split by line wrapping.
I felt the lower complexity here outweighed the potential slight loss in efficiency.
We can always revisit this if this turns out to be a real problem.
Differential Revision: https://phabricator.services.mozilla.com/D138105
James Teh
Eitan Isaacson
criss
Marian-Vasile Laza
Morgan Reschenberg
Iulian Moraru
Butkovits Atila
smolnar