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
User may paste a lot with pressing Accel+V for a while (i.e., with auto repeat).
So, calling nsIEditor::Paste() may be in a hot path and we can now make
non-virtual public method with AsHTMLEditor().
Differential Revision: https://phabricator.services.mozilla.com/D2993
--HG--
extra : moz-landing-system : lando
The accessibility tests currently rely, in many places, on lexical variables
defined in global frame scripts being available to other non-global frame
scripts. While that is currently the case, it will stop being so soon.
And, while the simplest solution would be to define them as properties on the
frame message manager by using `var` rather than `let`, storing references to
the current content window in a frame script scope is unsafe at best, and
should be avoided at all costs.
MozReview-Commit-ID: 4FCGtLgcFzl
--HG--
extra : rebase_source : d21206c9f119ca0ce61f9956f84a2e2d11484bca
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
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
We need to be able to call these methods from const methods, so they must take a const Accessible*.
MozReview-Commit-ID: CDsWZG1ik31
--HG--
extra : rebase_source : 4721669afcd9101cb017361bd8f87fb8a860664a
Summary:
This patch allows parsing generic types, such as Sequence<T>, in XPIDL. It does
this by introducing a new type, TypeId, which contains both the name string and
an optional list of generic parameters.
Various places which use the xpidl.py library had to be updated to construct one
of these TypeId objects, as TypeId and `str` are not compatible types.
Depends On D2106
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2109
This again exposes the accelerator (e.g. Ctrl+T for New Tab) for menu items via IAccessible::accName on windows.
Bug 1438193 made Accessible::Name const.
On Windows, XULMenuitemAccessibleWrap::Name is overridden to append the accelerator to the name.
Unfortunately, this override was missed when converting Name to const (and wasn't a compile error because it didn't use the override keyword).
As such, this override stopped being called; we always called the const version, since that's the one inherited into AccessibleWrap.
Making this const causes this override to be called.
MozReview-Commit-ID: 7Gb199mzhHa
--HG--
extra : rebase_source : 41d15042a09e4743d127fb12378c775099aa09a0
IA2 now has IA2_ROLE_CONTENT_INSERTION/DELETION.
Mac has AXInsert/DeleteStyleGroup subroles.
We now create accessibles for these elements and expose the appropriate role.
For ATK, there is no specific role for these, so we just use the generic ATK_ROLE_SECTION.
MozReview-Commit-ID: 2khzRa7BQ6z
--HG--
extra : rebase_source : e1c84bdef9a23b225e9870660050790df94c4beb
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
This patch does several things:
1. When "domwindowopened" is dispatched it often doesn't have a
document yet, so we need to wait for it to load before determining if we
should attach it.
2. Instead of managing individual message managers use a broadcaster
and load delayed scripts. This makes new window additions more robust.
3. A content script now doesn't need a ready/start message but
initializes in-line. This added more complexity which we don't need. All
the info that we passed to it in AccessFu:Start can be gotten in other
ways (also, Services.appinfo.ID now works in child processes, so no need
for that).
4. Tweaked the tests to support inline frame script initilization.
5. Removed the scroll callback from content-script.js that was not used
anymore.
It's currently only accessible on XULDocument and XULElement, but that makes porting existing
JS to run in an HTML document inconvenient. We could alternatively change calling JS, but
this can be easily moved and exposed in chrome contexts.
MozReview-Commit-ID: JitYET20NSE
--HG--
extra : rebase_source : 75d823c688cba8d84dc19705e83284be383962f2
Before this change, we accessed the browser URL in the following ways:
- "chrome://browser/content/browser.xul"
- "chrome://browser/content/" (which redirects to chrome://browser/content/browser.xul)
- Services.prefs.getCharPref("browser.chromeURL") which returns "chrome://browser/content/"
- getBrowserURL() from utilityOverlay.js
MozReview-Commit-ID: I5vtRke1x9t
--HG--
extra : rebase_source : c525350a1954740873e85b045cbb14a8b43aa89d
It is conforming in HTML to use a div to group dt/dd elements.
Previously, we didn't create an accessible for dt/dd elements in this case.
MozReview-Commit-ID: 8GDDxU3RbLd
--HG--
extra : rebase_source : 558a67e1b21583c6fac766ee1d1a24606976177f
nsIEditor::GetDocumentIsEmpty() is a virtual code and there is non-virtual
method, TextEditor::IsEmpty(). So, any callers in C++ should use
TextEditor::IsEmpty() instead.
MozReview-Commit-ID: CQE8LP6XI96
--HG--
extra : rebase_source : e0027c3d71856adcd5fa7820bf936a6b405560c5
This SelectionManager assertion fails when running the testing/marionette/harness/marionette_harness/tests/unit/test_navigation.py TestBackForwardNavigation.test_non_remote_about_pages marionette test. This assertion failure is bug 1126649.
This patch DOES NOT fix the cause of the assertion failure (a missing HyperTextAccessible). It just replaces this failing NS_NOTREACHED with NS_ERROR because I am removing the NS_NOTREACHED macro.
MozReview-Commit-ID: EVfyZlMwN4p
--HG--
extra : source : 676e9eb651d710bae1c76c3dae86a5cb1bded4d7
extra : intermediate-source : 6bce8da694e6803b04e7492094fc65b2b0e49bbf
extra : histedit_source : 57073997ac23879767937eaa3b42f78f60d1c942
This prepares for the removal of the "listbox" element and binding.
MozReview-Commit-ID: G1OxRGBphmw
--HG--
extra : source : 65d7ca38bd086abe7df0e50e9e5a9ba1d70202c3
In the case of an unbound pivot (endOffset == startOffset == -1), we
should move to the last substring in the current position when
movePreviousByText is called.
For example, <input type="range"> maps to role="slider", so aria-valuetext should be supported.
MozReview-Commit-ID: IYBVTHP3ZLo
--HG--
extra : rebase_source : 906dfacf92d040abf97b46ff67bafbabc5c9a1ea
We don't fire a state change for the focused state, since that would be redundant given that we fire a focus event.
However, that also means the handler cache previously didn't get invalidated when there was a focus change without any other update.
That resulted in stale focused states, which could mean an object was exposed as focused when it wasn't.
Invalidating the cache for focus events ensures the focused state is always up to date.
MozReview-Commit-ID: DZTJMbiTwgt
--HG--
extra : rebase_source : 9977699999218432b07c4af2149cba6e0de466af
After page load the document is focused and the entire subtree is
spoken. It should only speak the name.
--HG--
extra : rebase_source : bfc5542969fa29c45b9617d873a3dba7bf1a47c2
nsIAccessibleText.setSelectionBounds should accept a start offset that is larger than an end offset. This is an indica tion that it is a reverse selection, and the caret should be at the start of the selection.
This should also be consistent with how multiple range selections work interactively - the caret should re
main at the last offset reached.
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
If GetInitialInterceptorForIID fails, the live set lock is not released in most cases, but the newly created Interceptor will be destroyed.
The Interceptor's destructor tries to acquire the live set lock again, but that causes a deadlock, since reentry is no longer allowed for a mutex after bug 1364624.
GetInitialInterceptorForIID now ensures the live set lock is always released on failure, thus preventing the deadlock.
MozReview-Commit-ID: z0Q7JLnJXQ
--HG--
extra : amend_source : 0b9837e5500754b5782e72337fc59b7904c5e29c
For example, this can happen when choosing File menu -> new Tab.
Focus briefly returns to the document in the original tab, so we ask that document to restore focus.
The remote document then sends a focus event to the parent.
However, before the parent can process that event, focus has already moved to the address bar for the new tab.
With this check, we discover that focus is now in the chrome and thus avoid firing the event for the remote accessible.
MozReview-Commit-ID: 7k58dzREqZD
--HG--
extra : rebase_source : 51303f54293957f562e8540c8bf98f821694be54
For example, this can happen when choosing File menu -> new Tab.
Focus briefly returns to the document in the original tab, so we ask that document to restore focus.
The remote document then sends a focus event to the parent.
However, before the parent can process that event, focus has already moved to the address bar for the new tab.
With this check, we discover that focus is now in the chrome and thus avoid firing the event for the remote accessible.
MozReview-Commit-ID: 7k58dzREqZD
--HG--
extra : rebase_source : 070d3a6b5032bd6d4cd36fb054be04509bb0faae
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
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle
that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the place.
Additionally, if moving entries is implemented via memcpy (which is
quite common), PLDHashTable copying around bits *again* is inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead
of copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
Summary:
This patch allows parsing generic types, such as Sequence<T>, in XPIDL. It does
this by introducing a new type, TypeId, which contains both the name string and
an optional list of generic parameters.
Various places which use the xpidl.py library had to be updated to construct one
of these TypeId objects, as TypeId and `str` are not compatible types.
Depends On D2106
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2109
Cache AccessibleNode and make it able to operate the same instance by nsINode::GetAccessibleNode
--HG--
extra : rebase_source : 063eec8658af020f5408260d7d581ee76a04bd37
* Create BLOCKQUOTE internal role (also needed for correct exposure of
blockquote element on ATK)
* Add new ARIA roles to internal ARIA map
* Add new roles to existing ARIA roles mochitest and update blockquote
element test to reflect mapping to the new internal role
* Create BLOCKQUOTE internal role (also needed for correct exposure of
blockquote element on ATK)
* Add new ARIA roles to internal ARIA map
* Add new roles to existing ARIA roles mochitest and update blockquote
element test to reflect mapping to the new internal role
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.
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
We expose the relevant APIs on textarea and input elements anyway
(chromeonly). The QIs will throw on a non-input or non-textarea element, but
none of these consumers expect that to happen.
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
There are some places where we have a thing which may not even be a node, and
we end up hardcoding the value of DOCUMENT_NODE there, because
"foo.nodeType == foo.DOCUMENT_NODE" will test true if foo is not a node: both
sides will be undefined.
Using concrete class types with static IIDs in QueryInterface methods is a
pretty common pattern which isn't supported by any existing helper macros.
That's lead to separate ad-hoc implementations, with varying degrees of
dodginess, being scattered around the tree.
This patch adds a helper macro with a canonical (and safe) implementation, and
updates existing ad-hoc users to use it.
MozReview-Commit-ID: HaTGF7MN5Cv
--HG--
extra : rebase_source : ace930129d85960d22bc3048ca3bb19bbbd4a63e
extra : histedit_source : 03a87f746d957789d41381e4e1bfcc4fd7eebaf2%2C9c5bae9feeeef7721105db67be0f83e0ded66bb7
Move from nsStyleColor::CalcComplexColor to StyleComplexColor::CalcColor.
MozReview-Commit-ID: FkYovvPZLc8
--HG--
extra : rebase_source : 54f1966e0ef9258f20e954cd6250774008eca04c
Also fixes existing code which fails the rule.
MozReview-Commit-ID: CkLFgsspGMU
--HG--
extra : rebase_source : 86a43837659aa2ad83a87eab53b7aa8d39ccf55b
None of the C++ callers of RemoveSelectionListener care about whether the
listener was already-added, and the only JS caller is in a test and knows the
listener was added. So the behavior change to no-op instead of throwing when
trying to remove a nonexistent listener is OK. Furthermore, the removal is
null-safe, so there's no point to explicitly failing if null is passed (which
it never is).
Since content can't directly add selection listeners, we can just use an
infallible append instead of returning errors callers don't check for anyway.
Also, no one passes null to AddSelectionListener, so we don't have to worry
about that part.
