Before this patch, we didn't set aria-valuetext when the value was initially empty, nor did we clear it after a value was set and subsequently cleared.
This resulted in incorrect numeric values being reported to users.
Now, we set aria-valuetext to "" in either of these cases.
Differential Revision: https://phabricator.services.mozilla.com/D125366
Before this patch, we didn't set aria-valuetext when the value was initially empty, nor did we clear it after a value was set and subsequently cleared.
This resulted in incorrect numeric values being reported to users.
Now, we set aria-valuetext to "" in either of these cases.
Differential Revision: https://phabricator.services.mozilla.com/D125366
This passes for me on try.
We do have some low frequency intermittent failures for this test, but they apply to all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D126428
Previously, the test asserted that the line offsets for an embedded object should be an empty range.
This is actually incorrect, since there is content on the line (an empty text box and a button).
Update this with the correct result, but mark it as an expected failure.
The new implementation fixes this, so once we enable it by default, we can assert success.
Differential Revision: https://phabricator.services.mozilla.com/D125670
By using a real image, and not a broken one, we avoid the recreation
that happens when the image gains and loses an alt. We can then rely on
name/description changes.
This is a more accurate test that doesn't rely on tree mutations.
Differential Revision: https://phabricator.services.mozilla.com/D124233
The summary class just had a moxExpanded which we already have in mozAccessible.
I think the former was added before the latter was generalized for aria-expanded usage.
Differential Revision: https://phabricator.services.mozilla.com/D123516
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
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
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
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
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
Morgan Reschenberg
Gijs Kruitbosch
Butkovits Atila
Eitan Isaacson
James Teh
Sandor Molnar
Niklas Baumgardner
Csoregi Natalia
Michelle Goossens
Ben Hearsum
Marian-Vasile Laza
Dorel Luca
Narcis Beleuzu
Noemi Erli
Christoph Kerschbaumer