This sets up the possibility of moving most non-gecko things to a base class, and
start a protocol to add for all the subclasses to implement as needed.
Differential Revision: https://phabricator.services.mozilla.com/D76920
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084
1. When we unmarshal a row/column header, cache it so we can get it by id later.
2. get_rowHeaderCells and get_columnHeaderCells use the header ids in the payload.
If the headers are in the cache (as per 1), return them to the client.
Otherwise, fall back to a cross-process call, which might happen if we haven't encountered the header yet.
Differential Revision: https://phabricator.services.mozilla.com/D76667
1. When we unmarshal a row/column header, cache it so we can get it by id later.
2. get_rowHeaderCells and get_columnHeaderCells use the header ids in the payload.
If the headers are in the cache (as per 1), return them to the client.
Otherwise, fall back to a cross-process call, which might happen if we haven't encountered the header yet.
Differential Revision: https://phabricator.services.mozilla.com/D76667
Previously, to get the column headers for a cell when there weren't explicit headers, we walked over all previous cells in the column looking for headers.
For large tables with thousands of rows, this was very expensive, particularly when Windows screen readers rendered virtual buffers, fetching headers for all cells.
To speed this up, we now lazily cache the previous column header for each cell.
We even cache whether there is no previous header, since that is quite common and we don't want to pointlessly walk in that case.
Subsequent cells utilise the cached values (if any) for prior cells.
We don't store the cache on individual TableCellAccessibles because that would require us to walk all cells to invalidate the cache, even if few or no cells had cached values.
Instead, we store the cache as a hash table on the TableAccessible.
This way, we can just clear the cache whenever a column header is added to the tree.
We invalidate the cache whenever a column header is bound to its parent.
We don't need to invalidate the cache for removals because we instead just ignore defunct Accessibles in the cache.
Differential Revision: https://phabricator.services.mozilla.com/D76106
In favor of the NativeAnonymous versions which they forward to.
Done automatically with:
rg -l 'IsInAnonymousSubtree' | xargs sed -i 's/IsInAnonymousSubtree/IsInNativeAnonymousSubtree/g'
And removing the function definitions afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D76681
These tests insert a <browser> into the DOM via tabbrowser, and
immediately try to get a hold to the underlying document right after.
However the a11y tree is constructed after frame construction, and with
bug 1584935 there's no longer a guarantee that it gets done in time
without these explicit flushes.
Note that I couldn't reproduce these failures locally, so take the
diagnostic with a grain of salt, but I believe it's accurate and that
this is the right fix.
Differential Revision: https://phabricator.services.mozilla.com/D75715
For an OOP iframe, the logged parent will be null and the logged root won't be the real top level document.
This is just the way things are and this might still be useful info sometimes, so we still log it, but make it clear in the log message that it's about the in-process tree.
Differential Revision: https://phabricator.services.mozilla.com/D74587
DocAccessibleParent::AddChildDoc sends a COM proxy for the embedded document to the embedder process hosting the iframe.
This gets returned as the child of the embedder OuterDocAccessible.
Whenever we send a proxy to a content process, we must hold a PreservedStreamPtr in the parent process.
Previously, we set mDocProxyStream on the parent (embedder) document.
However, if a document had multiple OOP iframes, this meant we ended up losing the PreservedStreamPtr for all but the last added child OOP document.
We now set mDocProxyStream on the child document instead, since there can only be one embedder OuterDocAccessible per child document.
Differential Revision: https://phabricator.services.mozilla.com/D74584
To improve performance for cross-process COM, we disable COM garbage collection in content processes for calls from our parent process.
However, this means we don't receive Release calls from in-process a11y clients.
For an Accessible, we get around this by explicitly disconnecting remote clients when the Accessible shuts down.
This doesn't cover COM objects which aren't interfaces of an Accessible; i.e. where the object has a different IUnknown to the Accessible.
This patch adds AccessibleWrap::AssociateCOMObjectForDisconnection to allow these objects to be tracked.
Tracked objects are then disconnected when the Accessible shuts down.
Differential Revision: https://phabricator.services.mozilla.com/D74999
Platform accessibles from proxies were not getting pruned. Also, there is no need
to walk up ancestors to find a pruning container since all pruning containers have direct
leaf children.
Differential Revision: https://phabricator.services.mozilla.com/D72482
This is something that was implemented a long time ago, but it isn't covered in any spec, other browsers don't implement it and I don't know of any usage in the wild.
This doesn't work with OOP iframes, since what we're doing here requires the documents to be in the same process.
Given it isn't used or specified, the simplest solution is to just remove the behaviour altogether.
Differential Revision: https://phabricator.services.mozilla.com/D74628
This depends on richlistitem's nsIDOMXULSelectControlItemElement::label implementation, which does the wrong thing in several cases.
We could make this use a11y name computation, but I can't find any other list box implementation that exposes accessible value on the list box itself, so I don't see any reason to keep this.
Differential Revision: https://phabricator.services.mozilla.com/D74372
This is not strictly related to this bug, but I'm touching the surrounding code and I've been confused by this on several occasions.
The previous comments suggested that NameFromAssociatedXULLabel (which uses XULLabelIterator) looks at child labels.
This is incorrect: XULLabelIterator only looks at <label control="id">.
The inclusion of child labels in the name comes from GetNameFromSubtree, which is called elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D74371
This was only used for richlistitems, but the richlistitem implementation of this property did the wrong thing in several cases.
The a11y engine's label computation code generally does a better job.
Where the label does need to be overridden in specific cases, we should use ARIA instead.
Differential Revision: https://phabricator.services.mozilla.com/D74370
As of bug 1621451 this argument was ignored, but it just silently runs your code with `python3` if you pass it anyway. Ensure this doesn't happen any more, and protect against any other unexpected arguments as well.
Differential Revision: https://phabricator.services.mozilla.com/D73485
`ply`, [by design](https://github.com/dabeaz/ply/issues/79), does not produce reproducible table files; hence bug 1633156. (Note that this was *always* true, but only became a problem once we switched to Python 3, which has more unpredictable dict iteration order than Python 2.7, at least prior to [3.7](https://docs.python.org/3/whatsnew/3.7.html#summary-release-highlights).)
In any other circumstance I would consider submitting a patch to `ply` to fix this, but as of the [in-progress version 4.0 of the library](https://github.com/dabeaz/ply/blob/master/CHANGES), it doesn't even emit this cached data any more, and indeed the [latest version of the code](1fac9fed64/ply) doesn't even call `open()` at all except to do logging or to read the text data to be parsed from `stdin`. So if we were going to pin our future on `ply` and upgrade to later versions of the library in the future, we would have to live in a world where `ply` doesn't generate cached table files for us anyway.
Emitting the cached table files so later build steps can consume them is an "optimization", but it's not clear exactly how much actual value that optimization provides overall. Quoth the `CHANGES` file from that repository:
```
PLY no longer writes cached table files. Honestly, the use of
the cached files made more sense when I was developing PLY on
my 200Mhz PC in 2001. It's not as much as an issue now. For small
to medium sized grammars, PLY should be almost instantaneous.
```
In practice, I have found this to be true; namely, `./mach build pre-export export` takes just about as long on my machine after this patch as it did before, and in a try push I performed, there's no noticeable performance regression from applying this patch. In local testing I also found that generating the LALR tables in calls to `yacc()` takes about 0.01s on my machine generally, and we generate these tables a couple dozen times total over the course of the `export` tier now. This isn't *nothing*, but in my opinion it's also not nearly long enough where it would be a concern given how long `export` already takes.
That `CHANGES` file also stresses that if caching this data is important, we have the option of doing so via `pickle`. If and when we decide that re-enabling this optimization is valuable for us, we should take control of this process and perform the generation in such a way that we can guarantee reproducibility.
Differential Revision: https://phabricator.services.mozilla.com/D73484
Eitan Isaacson
Emilio Cobos Álvarez
Razvan Maries
Morgan Reschenberg
James Teh
Noemi Erli
Sylvestre Ledru
Bogdan Tara
Yura Zenevich
Coroiu Cristina
Aaron Klotz
Marco Zehe
Ricky Stewart