We naively remove and then recreate accessibles when their content's
frame is reconstructed. By delaying the removal until we are certain the
content does not have a new layout frame, we can cut down on redundant
recreations.
When reconstructed content is re-inserted we can check it and its
subtree for missing frames and prune those accessibles from the tree.
Differential Revision: https://phabricator.services.mozilla.com/D38380
--HG--
extra : moz-landing-system : lando
Previously, we would always calculate the name for tr elements from their descendants unconditionally. Assistive technologies aren't using this information, moreover, it causes problems if the name gets too long, for example in layout tables.
We now only calculate the name if the tr element has an explicit ARIA role.
Differential Revision: https://phabricator.services.mozilla.com/D39314
--HG--
extra : moz-landing-system : lando
`NS_FRAME_IS_DIRTY` being set on a frame has always meant that that
frame and all of its descendants need to be reflowed. What the main
patch on this bug is changing is when it gets propagated to descendants;
prior to that patch it gets propagated during reflow, whereas after the
patch it gets propagated when the bit is set. This means that
`NS_FRAME_IS_DIRTY` is now (after the patch) a somewhat more reliable
indicator of whether a frame requires reflow than it was before.
However, this has a strange interaction with the particular sequence of
operations that test_list.html performs. In particular, test_list.html:
(1) makes a style change that requires reflow,
(2) flushes style (but not layout), and
(3) gets the name of an accessible whose layout was dirtied by the style change.
Getting this name ends up here:
```
nsTextFrame::GetRenderedText at layout/generic/nsTextFrame.cpp:9600
nsTextEquivUtils::AppendTextEquivFromTextContent at accessible/base/nsTextEquivUtils.cpp:127
nsTextEquivUtils::AppendFromAccessible at accessible/base/nsTextEquivUtils.cpp:174
nsTextEquivUtils::AppendFromAccessibleChildren at accessible/base/nsTextEquivUtils.cpp:162
nsTextEquivUtils::GetNameFromSubtree at accessible/base/nsTextEquivUtils.cpp:39
mozilla::a11y::Accessible::NativeName at accessible/generic/Accessible.cpp:1991
mozilla::a11y::HyperTextAccessible::NativeName at accessible/generic/HyperTextAccessible.cpp:1760
mozilla::a11y::Accessible::Name at accessible/generic/Accessible.cpp:149
mozilla::a11y::xpcAccessible::GetName at accessible/xpcom/xpcAccessible.cpp:245
NS_InvokeByIndex at xpcom/reflect/xptcall/md/unix/xptcinvoke_asm_x86_64_unix.S:106
```
What the main patch in the bug has changed is whether this `nsTextFrame`
has the `NS_FRAME_IS_DIRTY` bit set at this point. This means that
`GetRenderedText` will bail out without reporting the text, because the
frame is marked dirty.
On the assumption that this action -- getting accessible names while
frames are dirty -- is an artificial situation set up in the test and
not a real-world situation that we need to care about, I'm proposing
that we make the straightforward adjustment to the test: flush layout
in addition to flushing style at step (2) above, so that the test works
again. As long as that assumption is correct, I think this should be
fine. (I'd note that this is the *only* test that breaks as a result of
the patch.)
If, on the other hand, we actually do care about what accessible names
return while layout state is dirty and reflow is needed, we should
probably improve `nsTextFrame::GetRenderedText` so that it can somehow
report useful state even when `NS_FRAME_IS_DIRTY` is set, or something
else more complicated.
Differential Revision: https://phabricator.services.mozilla.com/D36423
--HG--
extra : moz-landing-system : lando
Toolbar buttons in XUL can now have labels inside them to provide the actual caption for the button. Adjust the accessibility module to allow label elements as acceptable children for the toolbarbutton element so the algorithm can pick up their text for the button's name.
Differential Revision: https://phabricator.services.mozilla.com/D12527
--HG--
extra : moz-landing-system : lando
Proper native "groupbox" styling depends on the structure of the XBL binding. By restyling the Page Info dialog, the native styling is now unused except for the Print Page Setup dialog on Windows. The native apperance is thus not applied by default anymore, and the "groupbox" element can just be used semantically for accessibility. The Print Page Setup dialog applies the native styling on its own in a way that still works on Windows.
The only other consumers of "groupbox" are the in-content Preferences pages and dialogs. These are updated to use simpler styles that don't depend on the binding structure.
Differential Revision: https://phabricator.services.mozilla.com/D8752
--HG--
extra : rebase_source : af36d911980517f9b53036f4cd4f800c5e20ad22
Change the name calculation rule of HTML 'table' element from eNoNameRule
to eNameFromSubtreeIfReqRule. That way the table won't get an accessible
name, but will be descended when building a name from a parent element's
contents.
--HG--
extra : rebase_source : 218aec9f90b0c420a5f6785e929e5512b6704567
This prepares for the removal of the "listbox" element and binding.
MozReview-Commit-ID: G1OxRGBphmw
--HG--
extra : source : 65d7ca38bd086abe7df0e50e9e5a9ba1d70202c3
Previously, every test and support file would be synced to the objdir
when running any test. Now that only those support files and tests requested
are synced, we note support files required beyond those in a test's
directory in ini manifests.
MozReview-Commit-ID: EmlDz9d4lqt
