Now that we cache ActionCount, we can check for the absence of actions
and return false, or send an async message and return true.
Differential Revision: https://phabricator.services.mozilla.com/D135909
In terms of the C++ code, this patch does basically one thing, which is
allowing creating option / optgroup accessibles without a frame for
comboboxes, and tracking mutations like layout does.
It seems this should be straight-forward, but handling mutations got a
bit complicated. We don't want to forcibly re-create accessibles, so we
want to re-use the PruneOrInsertSubtree logic that ContentInserted uses.
But determining whether we need to create the accessible requires
having flushed styles, so I added a ScheduleAccessibilitySubtreeUpdate
API to trigger that from WillRefresh once style and layout are
up-to-date.
The rest of the test updates should be sort of straight-forward. They
reflect two changes:
* <option> accessibles are leaves now (so they don't have text
children). Note that we still have the right native name and so on,
using the same logic we use to render the label.
* In 1proc tests, the focus no longer goes to the <option>, and uses
the same code-path that e10s does (moving focus to a <menulist> in
the parent process). Since that wasn't easy to test for (afaict) and
we have browser tests to cover that
(browser_treeupdate_select_dropdown.js, etc), I've decided to just
remove the tests that relied on the previous code-path, as they were
testing for a codepath that users weren't hitting anyways.
I've tested this with JAWS and Orca and behavior seems unchanged to my
knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D133098
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
In terms of the C++ code, this patch does basically one thing, which is
allowing creating option / optgroup accessibles without a frame for
comboboxes, and tracking mutations like layout does.
It seems this should be straight-forward, but handling mutations got a
bit complicated. We don't want to forcibly re-create accessibles, so we
want to re-use the PruneOrInsertSubtree logic that ContentInserted uses.
But determining whether we need to create the accessible requires
having flushed styles, so I added a ScheduleAccessibilitySubtreeUpdate
API to trigger that from WillRefresh once style and layout are
up-to-date.
The rest of the test updates should be sort of straight-forward. They
reflect two changes:
* <option> accessibles are leaves now (so they don't have text
children). Note that we still have the right native name and so on,
using the same logic we use to render the label.
* In 1proc tests, the focus no longer goes to the <option>, and uses
the same code-path that e10s does (moving focus to a <menulist> in
the parent process). Since that wasn't easy to test for (afaict) and
we have browser tests to cover that
(browser_treeupdate_select_dropdown.js, etc), I've decided to just
remove the tests that relied on the previous code-path, as they were
testing for a codepath that users weren't hitting anyways.
I've tested this with JAWS and Orca and behavior seems unchanged to my
knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D133098
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
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
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
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
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
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
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
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
I'm not sure in what markup/style scenario a list item accessible
wouldn't have a frame, but would have a bullet. Apparently that can
happen in the wild. Added an assertion, hopefully we can trip it on
something reproducable in the future.
Differential Revision: https://phabricator.services.mozilla.com/D117347
In 1513447 there is a demonstrated instance in which the generated
marker is replaced with another one and throws the list item bullet
state into an unknown state. To remedy this we need to observe when such
elements are removed and added.
Instead of that, I opted to finally make the bullet accessible a real
content-backed accessible. This should help with other issues that pop
up when the list item overrides children management and keeps an
artificial accessible as its first child.
Differential Revision: https://phabricator.services.mozilla.com/D110719
This is in preparation for the next patch the virtualizes ChildAtPoint
in the Accessible class. LocalChildAtPoint allows us to house local-only
child at point implementations.
Differential Revision: https://phabricator.services.mozilla.com/D106679
eHasNumericValue should probably not be a state anyway. We need both of
these types because we currently send eHasNumericValue and
ActionCount != 0 as interface flags when creating proxies.
Differential Revision: https://phabricator.services.mozilla.com/D104914
This is a collaboration between clang-tidy and clang-format.
clang-tidy uses compiled code paths, so this patch is linux specific.
Differential Revision: https://phabricator.services.mozilla.com/D105669