In bug 1507365, we introduced the ability of nested label children of toolbar buttons to provide the accessible name for a xul:toolbarbutton element. However, the XBL of xul:toolbarbutton causes the creation of a label accessible even if no xul:label child is present, and only the label attribute is being used. The nsIAccessibleText interface on such labels is, however, completely broken. This causes NVDA's mouse tracking, which always uses the deepest nested child, to fail. As a result, when hovering over Hamburger menu items, the announcement would be wrong, e. g., lag one behind the actual button the mouse is hovering over.
To fix this, we only accept xul:label children if they come from real XUL markup, not from the label attribute and the XBL creating the label. This means that some of the test changes from bug 1507365 have to be reverted to accommodate the new old behavior. But the new test for an actual label child still passes.
Differential Revision: https://phabricator.services.mozilla.com/D14469
--HG--
extra : moz-landing-system : lando
Simply decouple the check for the checked attribute from the one for the type attribute.
Differential Revision: https://phabricator.services.mozilla.com/D12632
--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
The XULSelectControlAccessible selection methods don't handle ARIA selection.
Therefore, if aria-multiselectable is set, use the base implementation of the selection retrieval methods.
We don't bother overriding the selection setting methods because implementations (e.g. browser tabs) don't support setting of aria-selected by the a11y engine and we still want to be able to set the primary selected item according to XUL.
Being able to retrieve multiple selection programmatically is far more important than being able to set it.
MozReview-Commit-ID: CmVp9KyieMY
--HG--
extra : rebase_source : e3fa93aad4726b322956babb5422dceebfa0fbb2
Without this, accessibility clients don't get notified about the newly focused item.
For example, this meant that nothing was reported by screen readers when switching tabs in Thunderbird with control+tab.
MozReview-Commit-ID: F7vqvLXzeJR
--HG--
extra : rebase_source : debd649415cdc7417660c5846a923a5cc8edad79
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
There is one actual behavior change here, in the webidl version of
TreeBoxObject::GetCellAt. I believe this change fixes a leak of the
nsTreeColumn, but could use careful review.
I tried to avoid changes not needed to get this compiling. There will be a lot
more cleanup in the next few changesets.
