Added long press as well as the old tooltip language back
and updated 2 tests.
Differential Revision: https://phabricator.services.mozilla.com/D61717
--HG--
extra : moz-landing-system : lando
Added right click on new tab button to open containers menu.
Removed long press and added option to enable left click in preferences menu.
Renamed privacy.userContext.longPressBehavior to privacy.userContext.newTabContainer.enabled
Differential Revision: https://phabricator.services.mozilla.com/D58410
--HG--
extra : moz-landing-system : lando
This means that for any other ARIA role, we will expose the DOCUMENT role on the DocAccessible.
Differential Revision: https://phabricator.services.mozilla.com/D60632
--HG--
extra : moz-landing-system : lando
After bug 981248, <input type="number"> no longer has an anonymous text input.
Instead, the <input type="number"> itself manages the text.
Previously, the a11y code which fired value change events for text changes only did this for combo boxes and role ENTRY.
This meant a value change event was no longer fired for <input type="number">.
This condition has now been extended to include role SPINBUTTON.
This fixes reporting of <input type="number"> changes for JAWS.
Differential Revision: https://phabricator.services.mozilla.com/D60101
--HG--
extra : moz-landing-system : lando
1. Implement ProxyAccessible::TakeFocus on Windows.
2. Use this implementation in xpcAccessible::TakeFocus like we do on other platforms.
3. Enable accessible/tests/browser/fission/browser_take_focus.js on Windows, since it now works.
Differential Revision: https://phabricator.services.mozilla.com/D59977
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Previously, when opening the dialog, we only waited for a reorder event.
This could mean we programmatically closed the dialog before it was ever focused.
That in turn would mean that focus would never be fired on the previous window when the dialog was closed, causing the close dialog test to time out.
Differential Revision: https://phabricator.services.mozilla.com/D59826
--HG--
extra : moz-landing-system : lando
This reverts the change I made in bug 1572811, and instead fixes a much
more narrow case when the inner table frame is mid-construction.
Differential Revision: https://phabricator.services.mozilla.com/D58570
--HG--
extra : moz-landing-system : lando
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
--HG--
extra : moz-landing-system : lando
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
--HG--
extra : moz-landing-system : lando
Previously, due to bug 33654, we incorrectly added the width of the scrollbars to the textarea.
This was causing lines to be limited to 6 characters on ubuntu 18.04, even though we set cols="5" and thus expect 5 characters.
Setting scrollbar-width: none on the textarea works around this.
Differential Revision: https://phabricator.services.mozilla.com/D55205
--HG--
extra : moz-landing-system : lando
A XUL <label control="id"> can refer to an HTML element.
Keyboard and mouse support for this already works, but previously, this wasn't being exposed via accessibility APIs.
1. Split the code to get the name from an associated XUL label out of Accessible::XULElmName into a new function Accessible::NameFromAssociatedXULLabel.
2. Use NameFromAssociatedXULLabel for HTMl elements.
3. Update AccessKey and RelationByType to support HTML elements with associated XUL labels.
4. Rename accessible/tests/mochitest/actions/test_keys_menu.xhtml to test_keys.xhtml so it can cover accessKey outside of menus.
5. Add tests.
Differential Revision: https://phabricator.services.mozilla.com/D55057
--HG--
rename : accessible/tests/mochitest/actions/test_keys_menu.xhtml => accessible/tests/mochitest/actions/test_keys.xhtml
extra : moz-landing-system : lando
Mark the html:mark element to the new ROLE_MARK, which currently maps the same as role_text, and the xml-role of "mark", make sure we expose the roleDescription on Mac, and adjust the test so it tests that the attributes don't pick up any unexpected color for this particular element. So, the background attribute is empty when there is no unexpected, non-default background color.
Differential Revision: https://phabricator.services.mozilla.com/D52989
--HG--
extra : moz-landing-system : lando
If an embed or object doesn't specify a URL (or specifies a URL which isn't web content), it won't be created as an OuterDocAccessible.
For example, an embed with no src will be created as a generic HyperTextAccessible.
If the URL later changes to refer to web content, we must recreate as an OuterDocAccessible.
Previously, we didn't recreate, which was causing an assertion and may have caused other strange issues as well.
Differential Revision: https://phabricator.services.mozilla.com/D52292
--HG--
extra : moz-landing-system : lando
Sometimes, depending on how children were changed, children might be in the insertion list out of order; e.g. [child2, child1].
It's also possible that an earlier child (child1 in the above example) is being moved out of another container.
When processing the earlier insertion (child2), we'll determine we need to move it within its parent and will fetch its new previous sibling so we can move it into the right place.
However, in this case, the new previous sibling (child1) will be in the wrong container.
We can't move in that case; the new previous sibling's index in parent will obviously be wrong, since it's relative to the wrong container.
Therefore, we just skip the move.
Since the previous sibling (child1) is later in the insertion list, the ordering will be corrected when we process that insertion.
Differential Revision: https://phabricator.services.mozilla.com/D51037
--HG--
extra : moz-landing-system : lando
OuterDocAccessible has some special behaviour.
We really shouldn't try to use some other class for iframes.
Anyway, making an iframe part of an ARIA table won't work for other reasons, plus I'm not sure it makes much sense.
Differential Revision: https://phabricator.services.mozilla.com/D50769
--HG--
extra : moz-landing-system : lando
Yura Zenevich
Kendall Werts
Morgan Reschenberg
Tim Nguyen
Kendall Werts
James Teh
shindli
Brindusan Cristian
Emilio Cobos Álvarez
Mihai Alexandru Michis
Eitan Isaacson
Alexander Surkov
Bogdan Tara
Hiroyuki Ikezoe
Mark Banner
Taylor
Marco Zehe
Dorel Luca
Csoregi Natalia
Ehsan Akhgari
Marco Bonardo
Harry Twyford