Changed the browser and mochitest name tests to rely exclusively on name change
events. To make this happen, I fixed all the cases where we were
event-deficient in the code:
* Examine target in PushNameOrDescriptionChange if it has eNameFromSubtreeRule.
Fixes cases where a text change event happens with the subtree name root as target.
* Change in aria-labelledby should always result in a name change event because
that attribute has highest prescedence.
* Add eHasNameDependent/eHasDescriptionDependent context flags when dependee accessible
is added after dependent accessible to tree.
* Handle value attribute change in HTML buttons and determine if they should trigger a
name changed event.
* Use accessible tree instead of content tree when calculating HTMLSelectOptionAccessible
name, this keeps the PushNameOrDescriptionChange sees in name flags consistent with
the actual tree.
* Handle label attribute change in select options and determine if they should trigger
a name changed event.
* Determine if s summary attribute change on a table triggers a name change event.
* If a title attribute is changed, reliably fire a name change event if
it is used in name calculation.
Differential Revision: https://phabricator.services.mozilla.com/D121580
Needed to tweak tests a bit because the code is now more descerning
wheter to fire an event or not. Will do so only if the state actually
changes.
Depends on D120901
Differential Revision: https://phabricator.services.mozilla.com/D120902
Also folded ARIAAttributeChanged into DOMAttributeChanged temporarily.
Will streamline that further in the next patch where state changes are
done a bit better.
Depends on D120900
Differential Revision: https://phabricator.services.mozilla.com/D120901
Needed to tweak tests a bit because the code is now more descerning
wheter to fire an event or not. Will do so only if the state actually
changes.
Depends on D120901
Differential Revision: https://phabricator.services.mozilla.com/D120902
Also folded ARIAAttributeChanged into DOMAttributeChanged temporarily.
Will streamline that further in the next patch where state changes are
done a bit better.
Depends on D120900
Differential Revision: https://phabricator.services.mozilla.com/D120901
Needed to tweak tests a bit because the code is now more descerning
wheter to fire an event or not. Will do so only if the state actually
changes.
Depends on D120901
Differential Revision: https://phabricator.services.mozilla.com/D120902
Also folded ARIAAttributeChanged into DOMAttributeChanged temporarily.
Will streamline that further in the next patch where state changes are
done a bit better.
Depends on D120900
Differential Revision: https://phabricator.services.mozilla.com/D120901
Previously, we used GetFlattenedTreeParent from the list box to find the autocomplete popup.
After bug 1708735, this now returns a slot instead of the panel.
We now use GetParentElement instead, which works as expected and is consistent with other code in this class anyway.
I also added a new test so this doesn't regress yet again.
We already have test_focus_autocomplete.xhtml which is supposed to test this, but that test is broken, was thus disabled and is complicated enough that I don't think we're going to fix it any time soon, if ever.
The new test was triggering an assertion on Windows when trying to handle a caret event, so HyperTextAccessible::GetCaretRect had to be tweaked slightly to fix this.
Differential Revision: https://phabricator.services.mozilla.com/D121163
Needed to tweak tests a bit because the code is now more descerning
wheter to fire an event or not. Will do so only if the state actually
changes.
Depends on D120901
Differential Revision: https://phabricator.services.mozilla.com/D120902
Also folded ARIAAttributeChanged into DOMAttributeChanged temporarily.
Will streamline that further in the next patch where state changes are
done a bit better.
Depends on D120900
Differential Revision: https://phabricator.services.mozilla.com/D120901
If an iframe is hidden, its OuterDocAccessible will be destroyed, but the PBrowserBridge still exists.
Since the OuterDocAccessible was destroyed, its id can be reused.
Therefore, if a new embedder accessible hasn't already been set, clear the embedder accessible on PBrowserBridge.
This ensures that the wrong accessible can't accidentally be used when an OOP iframe document is added while the iframe is hidden.
Differential Revision: https://phabricator.services.mozilla.com/D121015
Needed to tweak tests a bit because the code is now more descerning
wheter to fire an event or not. Will do so only if the state actually
changes.
Depends on D120901
Differential Revision: https://phabricator.services.mozilla.com/D120902
Also folded ARIAAttributeChanged into DOMAttributeChanged temporarily.
Will streamline that further in the next patch where state changes are
done a bit better.
Differential Revision: https://phabricator.services.mozilla.com/D120901
This was previously used to wrap the COM proxy for the document child of an OOP iframe in a content process.
It was returned by OuterDocAccessible::LocalChildAt*.
Instead, BrowserBridgeChild now directly holds the COM proxy and MsaaAccessible traversal methods have specific code paths to return that as appropriate.
Since we no longer need the Windows OuterDocAccessible traversal overrides for OOP iframes nor remote top level documents, they have been removed entirely.
Differential Revision: https://phabricator.services.mozilla.com/D117526
This speeds up reflows on pages like view source that have a single
giant container. But this maybe slows down other cases? I'm not 100%
sure.
Differential Revision: https://phabricator.services.mozilla.com/D117948
This speeds up reflows on pages like view source that have a single
giant container. But this maybe slows down other cases? I'm not 100%
sure.
Differential Revision: https://phabricator.services.mozilla.com/D117948
ATK, Windows and XPCOM expect aria attribute keys to be stripped of
their aria- prefix. We should still store the item using the aria_ atom
and then strip the prefix when converting the key to a string.
Differential Revision: https://phabricator.services.mozilla.com/D116786
Sending these doesn't really do any harm, as we already disregard them in the parent process.
However, it's certainly unnecessary and wasteful.
Differential Revision: https://phabricator.services.mozilla.com/D116204
With the cache disabled (which was previously always the case), we create a RemoteAccessibleWrap for each RemoteAccessible, stored as the RemoteAccessible's "Wrapper".
This in turn creates an MsaaAccessible.
However, both of these are little more than stubs: the MsaaAccessible itself is never returned to clients and most of the methods would crash if called.
They exist only to store the MSAA id received from the content process and to return the COM proxy from the content process to clients.
With the cache enabled, we now create a real MsaaAccessible for each RemoteAccessible, stored as the RemoteAccessible's "Wrapper".
This MsaaAccessible is directly returned to clients.
Soon, it will generate its own id in the parent process and will delegate to the underlying RemoteAccessible to serve queries from clients.
As part of this:
1. We stop managing COM proxies in the parent process when the cache is enabled, since we don't need those and can't store them anyway.
2. We stop setting the id on the MsaaAccessible when the cache is enabled, since it will soon generate its own id like local MsaaAccessibles do.
3. OuterDocAccessible::ChildCount had to be tweaked so it doesn't try to return a RemoteAccessibleWrap when the cache is enabled. (It previously called RemoteChildDocAccessible, which fetches a RemoteAccessibleWrap.)
Differential Revision: https://phabricator.services.mozilla.com/D116191
Previously, we only checked whether the owner was a DOM descendant of the owned child.
However, the owner could be in a different DOM subtree, but an a11y descendant due to aria-owns relocation.
Now, we walk the a11y ancestors, doing the DOM descendant check again whenever the DOM lineage changes due to relocation.
Differential Revision: https://phabricator.services.mozilla.com/D115811
1. OuterDocAccessible::ChildCount was previously Windows only. Implement it for all platforms.
2. OuterDocAccessible::ChildAt included code for Windows which isn't necessary because it calls AccessibleWrap::LocalChildAt, not OuterDocAccessible::LocalChildAt (where the Windows specific RemoteAccessibleWrap stuff is implemented).
3. LocalAccessible::ChildAtPoint previously expected LocalChildAt() to succeed if ChildCount > 1. As per 1), this is no longer true for OuterDocAccessibles containing a remote document. Adjust accordingly.
4. IndexInParent on a top level remote document was previously returning -1. Implement DocAccessibleParent::IndexInParent to fix this.
5. Doing 4) means that RemoteNext/PrevSibling broke for top level documents because they use IndexInParent, but there is no remote parent. Add a specific early return for documents there.
Differential Revision: https://phabricator.services.mozilla.com/D115045
Eitan Isaacson
Marian-Vasile Laza
Dorel Luca
James Teh
Noemi Erli
Morgan Reschenberg
Florian Quèze
Butkovits Atila
Mats Palmgren
Kagami Sascha Rosylight
Masayuki Nakano