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
In-process iframes get a DocAccessibleChild, even though they're not top level in their process.
However, the parent IAccessible on DocAccessibleChild (sent from the parent process) is only relevant for the top level.
Previously, we used the parent IAccessible on the DocAccessibleChild for *all* documents, resulting in accParent returning null for in-process iframe documents.
Instead, we need to use the base implementation in this case.
Differential Revision: https://phabricator.services.mozilla.com/D74180
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
The code in mozAccessible SubRole was actually never executed for inputs, so the SearchField sub role was never set. Moved the implementation to mozTextAccessible. Also reenabled the tests from bug 1634373, which now pass.
Depends on D73308
Differential Revision: https://phabricator.services.mozilla.com/D73735
When an Accessible is removed, the AccGroupInfo for its siblings is marked dirty.
However, when AccGroupInfo::Update is called, it previously didn't clear mParent, which is used for the NODE_CHILD_OF relation.
This meant that if the conceptual group parent was removed and there was subsequently no conceptual parent, NODE_CHILD_OF would return an incorrect (potentially dead) Accessible.
Differential Revision: https://phabricator.services.mozilla.com/D73776
Fixes tooltips/menus in responsive design mode. A few accesibility tests
had to be adjusted since tooltips are now automatically created
for them.
Differential Revision: https://phabricator.services.mozilla.com/D72400
I also simplified mozTextLeafAccessible by redirecting value to title. And removing some dead methods. It previously was calling Text() on the text accessible, but this is not necessary since Name() returns
the same value.
Differential Revision: https://phabricator.services.mozilla.com/D72584
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
1. CleanupStaticIA2Data just called ReleaseStaticIA2DataInterfaces and zeroed memory.
We don't need it to zero memory, since we're going to delete the data anyway.
So, just call ReleaseStaticIA2DataInterfaces directly and get rid of CleanupStaticIA2Data.
2. CleanupDynamicIA2Data had a aZeroMemory argument, but no caller ever set it to true.
Therefore, get rid of the argument.
Differential Revision: https://phabricator.services.mozilla.com/D70297
This avoids separate cross-thread calls when marshaling each object returned from an IGeckoBackChannel bulk fetch method.
Differential Revision: https://phabricator.services.mozilla.com/D69485
This is the recommended role in the HTML Accessibility API Mappings draft[1].
Although Chrome and Safari just expose unlinked a tags as AXStaticText.
They also don't update the accessble if it gets an href. So while we
are doing this a bit differently, I think it is probably better. And VO is happy.
1. https://www.w3.org/TR/html-aam-1.0/#html-element-role-mappings
Differential Revision: https://phabricator.services.mozilla.com/D71260
I want to generalize it for other link stuff. Need a separate commit or
it is not recognized as a move, and won't retain history. For some reason.
Differential Revision: https://phabricator.services.mozilla.com/D71259
addA11yLoadEvent gets the contentWindow and wait for the document from that window to fire the load event.
Enabling the DocumentChannel for parent process load (or here in non-e10s mode) we have one extra event loop before the load starts.
So the window passed to addAllyLoadEvent would have been of the about:blank page.
The current code was based on an observable behaviour which was that the load was occuring synchronously.
DocumentChannel broke that assumption.
Differential Revision: https://phabricator.services.mozilla.com/D70799
Marco Zehe
Eitan Isaacson
James Teh
Morgan Reschenberg
Ricky Stewart
Botond Ballo
Mirko Brodesser
Jonathan Watt
Mike Hommey
Csoregi Natalia
Simon Giesecke
Daniel Varga
Brendan Dahl
Brindusan Cristian
Jean-Yves Avenard