Changed how our attributes tests work a bit to be single "is" test
instead of comparing each attribute separately. This allows passing a
todo option without it failing on attributes that are identical.
Differential Revision: https://phabricator.services.mozilla.com/D134974
The nsAccUtils method was a "fast" one for calculating set sizes and
conceptual parents. Unified it with
LocalAccessible::GetLevelInternal in Accessible::GetLevel with an
argument.
I also fixed select->optgroup->option group attributes.
Differential Revision: https://phabricator.services.mozilla.com/D134208
A move is sent to the parent process as a hide and then a show, even if the LocalAccessible wasn't recreated.
Previously, this meant that a new RemoteAccessible was created and the original RemoteAccessible was destroyed.
This was particularly problematic if the Accessible had focus and the client cached focus.
In that case, the client cache contained a dead Accessible, and since no focus event was fired (because it's the same Accessible in the content process), focus in the client was broken.
This also meant that there was a full cache push for a moved Accessible, which was wasteful.
To fix this:
1. Keep track of LocalAccessibles inserted during a tick.
2. Keep track of LocalAccessibles moved during a tick, including descendants. If a LocalAccessible was inserted during the same tick (1), don't track it as a move.
3. Before processing mutation events, tell the parent process about which Accessibles are about to be moved (2).
4. When sending a subtree to the parent process, don't send cache info for an Accessible which is being moved (2).
5. When the parent process receives a hide event, if there is an Accessible that is about to be moved (3), don't shut it down; allow it to be reused.
6. When the parent process receives a show event, if there is an Accessible that has an existing RemoteAccessible (5), reuse it.
Differential Revision: https://phabricator.services.mozilla.com/D132328
I removed the sync IPDL implementation of LinkIndexOf because we can calculate this in the parent process even with the cache disabled.
Differential Revision: https://phabricator.services.mozilla.com/D132200
1. There was a Windows non-cached RemoteAccessible implementation, but it was never actually called, so I removed it.
2. The sync IPDL RemoteAccessible implementation previously provided a boolean indicating success.
I removed this because the LocalAccessible implementation doesn't have this and it doesn't seem like remote is special in this respect.
Differential Revision: https://phabricator.services.mozilla.com/D132198
Add nsIAutoCompleteResult.isRemovableAt method, to indicate whether the value
is removable, and do nothing for Shift+Delete on the item when the value is
not removable.
Depends on D131740
Differential Revision: https://phabricator.services.mozilla.com/D131741
1. Use dom events in RootAccessible to fire ACTIVE state changes.
2. Add DOMMenuItemInactive events to nsListControlFrame and fire it on
the previously active option.
3. Don't fire those DOM events on collapsed combo boxes.
4. Add ACTIVE state change events for collapsed combo box options.
Differential Revision: https://phabricator.services.mozilla.com/D130298
Have ARIAActiveDescendantIDMaybeMoved call ARIAActiveDescendantChanged regardless of
widget focus state. The latter already checks if the widget is focused. This gives us
a chance to fire and ACTIVE state change regardless of focus state.
If an id or aria-activedescendant attribute is about to change, fire an
ACTIVE state change on the previously active accessible.
Differential Revision: https://phabricator.services.mozilla.com/D130296
By allowing async DOM events to be dispatched, and advancing the refresh
driver we can force some calls to NotificationController::WillRefresh
and flush out any pending notifications or events.
This lets us more reliably catch unexpected events without the need for
a sentinel event at the end.
Differential Revision: https://phabricator.services.mozilla.com/D130295
1. Use dom events in RootAccessible to fire ACTIVE state changes.
2. Add DOMMenuItemInactive events to nsListControlFrame and fire it on
the previously active option.
3. Don't fire those DOM events on collapsed combo boxes.
4. Add ACTIVE state change events for collapsed combo box options.
Differential Revision: https://phabricator.services.mozilla.com/D130298
Have ARIAActiveDescendantIDMaybeMoved call ARIAActiveDescendantChanged regardless of
widget focus state. The latter already checks if the widget is focused. This gives us
a chance to fire and ACTIVE state change regardless of focus state.
If an id or aria-activedescendant attribute is about to change, fire an
ACTIVE state change on the previously active accessible.
Differential Revision: https://phabricator.services.mozilla.com/D130296
By allowing async DOM events to be dispatched, and advancing the refresh
driver we can force some calls to NotificationController::WillRefresh
and flush out any pending notifications or events.
This lets us more reliably catch unexpected events without the need for
a sentinel event at the end.
Differential Revision: https://phabricator.services.mozilla.com/D130295
For example, when disabling an HTML input, we get an event for SUPPORTS_AUTOCOMPLETION among others.
If we continue with the test after that state change and there hasn't been an ENABLED/UNAVAILABLE state change, the cache won't be up to date.
Unfortunately, we can't use untilCacheOk here because we don't do a cache push for state changes.
Differential Revision: https://phabricator.services.mozilla.com/D129643
Since this is a chrome page we start honoring dark mode colors by
default, and after bug 1525107 that affects default background and text
colors, which these tests were hardcoding to black/white.
Differential Revision: https://phabricator.services.mozilla.com/D129983
Trickier than just listening for attributes on inputs since a form
can toggle autocomplete too.
Also fixed To32States to work on the 32nd bit.
Differential Revision: https://phabricator.services.mozilla.com/D128913
This can happen for display: contents.
In that case, there are no lines in the Accessible anyway, so returning an invalid TextLeafPoint (as we already did) is the correct thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D128319
This is a follow-up to my original patch.
It turns out that there is an assertion preventing use of document.write in privileged contexts which my original patch triggered.
Instead, set document.body.innerHTML.
Differential Revision: https://phabricator.services.mozilla.com/D128159
If a select's size is greater than 1 it won't be recreated when multiple
is added or removed. State change events should be fired in that case.
Differential Revision: https://phabricator.services.mozilla.com/D128277
If a <select> element with a default size or size of 1 gets the
`multiple` attribute it will change from a combobox button to an
embedded listbox. Similarly, if a select's size is set to something
larger than 1 it will convert from a combobox button to a listbox.
We should recreate the select's subtree because the
implementing classes are different for those two cases.
Differential Revision: https://phabricator.services.mozilla.com/D128276
We were force recreating accessibles when their aria-multiselectable
attribute changed. This was perhaps done in the past because of
percieved limitations in COM, or the implementing class was different.
This isn't the case anymore. We should instead fire state change events
when aria-multiselectable changes.
Differential Revision: https://phabricator.services.mozilla.com/D128275
Normally, we use data: URLs to load snippets as tab documents.
However, there is no way we can make this load in the parent process.
Using a chrome:// URL will allow us to load a file in the parent process.
For OOP iframes, we use document-builder.sjs to yield a document with supplied markup, but sjs doesn't work for chrome:// (since sjs is handled by our test web server).
Instead, for chrome://, we use an HTML file with an embedded script which replaces the content of the document with the supplied markup.
Differential Revision: https://phabricator.services.mozilla.com/D127769
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
UnifiedComplete must stick around to serve as an mozIPlacesAutoComplete implementation for XUL consumers like search.js and privacy.js.
Differential Revision: https://phabricator.services.mozilla.com/D119306
We are going to disallow having any remote <browser>s or <iframe>s inside
nsDeckFrame, so this test is no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D119066
For OOP iframes, a doc load complete event on the embedder document doesn't necessarily mean the iframe document has finished loading yet.
We already checked for the busy state on the nested iframe doc and waited for a doc load complete event in that case.
However, depending on timing, it might be possible there is no document at all (even a busy one), so we should wait for doc load complete in that case too.
This is a speculative fix; I wasn't able to reproduce this myself.
Differential Revision: https://phabricator.services.mozilla.com/D118123
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
The actual fix for this is in bug 1387308.
However, triggering this bug with an iframe in a remote document caused a crash in the parent process because the parent process was never sent the OuterDoc.
Given the added complexity here, I thought it worth having a separate test.
Differential Revision: https://phabricator.services.mozilla.com/D115812
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
Otherwise, callers might end up unintentionally binding the browser for lazy background tabs.
This was happening when a11y queried the LABEL_FOR relation while building the a11y tree, causing all lazy tabs to be loaded.
All callers of this method only need it to insert a browser when the tab is selected anyway.
Differential Revision: https://phabricator.services.mozilla.com/D114566
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 3) means that RemoteNext/PrevSibling crash for top level documents because they use IndexInParent, but there is no remote parent. Add assertions to ensure these are never called for documents.
6. Implement DocAccessibleParent::Next/PrevSibling so that RemoteNext/PrevSibling isn't used there (as per 4).
Differential Revision: https://phabricator.services.mozilla.com/D115045
Eitan Isaacson
Emilio Cobos Álvarez
James Teh
Morgan Reschenberg
Alexandru Michis
Joel Maher
Tooru Fujisawa
Butkovits Atila
Evgenia Kotovich
Noemi Erli
Andreea Pavel
Narcis Beleuzu
Cristian Tuns
Gijs Kruitbosch
Sandor Molnar
Niklas Baumgardner
Csoregi Natalia
Michelle Goossens
Ben Hearsum
Marian-Vasile Laza
Dorel Luca
Christoph Kerschbaumer
Iulian Moraru
Harry Twyford
Hiroyuki Ikezoe
Kagami Sascha Rosylight
Ryan VanderMeulen
Mats Palmgren
Ed Lee
Andrew Halberstadt