When the user is editing the text in the URL bar (typing, backspace, etc.), the first suggestion is always selected.
Because accessibility clients require autocomplete items to be "focused", the code needs to differentiate between explicit selection (e.g. via down/up arrow) and auto selection (e.g. when typing).
Otherwise, the focus continually moves away from the text box while the user is typing, as was previously occurring.
This makes it very difficult for the user to edit text, particularly backspace/delete.
There was a previous attempt to handle this, but it was somewhat fragile and broke completely some time ago.
Now, rather than trying to handle this based on autocomplete events, it is handled in the input and key press events.
For input events, accessibility focus is forced back to the text box and further accessibility focus events are suppressed.
For down arrow, up arrow, etc. key presses, accessibility focus events for suggestions are enabled.
This makes it easier to understand and predict the user experience, rather than relying on underlying autocomplete implementation details.
This is tested using an accessibility browser test, which makes it easier to make assertions about accessibility focus.
This also means that if the underlying implementation details change (e.g. HTML + aria-activedescendant instead of XUL + DOMMenuItemActive events), this test should still be valid and allow us to catch regressions.
Differential Revision: https://phabricator.services.mozilla.com/D5987
--HG--
extra : moz-landing-system : lando
For browser.xhtml childNodes includes whitespace nodes, while browser.xul
doesn't. This was done with other mochitests that load the browser window
in Bug 1482667.
Differential Revision: https://phabricator.services.mozilla.com/D5032
--HG--
extra : moz-landing-system : lando
Some classes of a11y are defined from both IUnknown and nsISupports. Both of
them have QueryInterface(). So, one of them is overridden by a sub class
hides the other and this is warned by clang. However, AccessibleWrap.h
prevents this warning since it's by design when the compiler is GCC.
So, it should do same thing when the compiler is clang.
Differential Revision: https://phabricator.services.mozilla.com/D4310
--HG--
extra : moz-landing-system : lando
This removes a number of references to rules that are now deprecated or removed from ESLint.
- no-native-reassign is replaced with no-global-assign
- no-spaced-func is replaced with func-call-spacing (where enabled)
Depends on D4944
Differential Revision: https://phabricator.services.mozilla.com/D4946
--HG--
extra : moz-landing-system : lando
Two cases were hiding permanently failing tests. I've commented those out and
filed bug 1487431.
Differential Revision: https://phabricator.services.mozilla.com/D4680
--HG--
extra : rebase_source : 232fa6173de8844a9c47d59926ec8e39d0640ecd
When dealing with an editor which contains multiple accessibles, the previous spelling error range might be in a previous accessible, not the accessible currently being queried.
In this case, DOMPointToOffset will return the length of this accessible.
Previously, we weren't checking for this and were overriding the start offset of the returned range regardless, resulting in broken offsets.
Now, we leave the start offset alone in this case.
Differential Revision: https://phabricator.services.mozilla.com/D3960
--HG--
extra : moz-landing-system : lando
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
