When checking for an accessible if it is a table row instead of a table cell, when retrieving the actual row at the given index, null check it to make sure we don't pass an invalid accessible to the TableAccessible::CellInRowAt method. I accidentally omitted that null check in the updated patch for bug 1486668.
Differential Revision: https://phabricator.services.mozilla.com/D7162
--HG--
extra : moz-landing-system : lando
Make LayerViewSupport, NPZCSupport, GeckoEditableSupport, and
SessionAccessibility use the new disposal mechanism to ensure the
disposal is performed safely.
Differential Revision: https://phabricator.services.mozilla.com/D7110
--HG--
extra : moz-landing-system : lando
The code does check for the case where a container has no children.
However, before it does so, it tries to check whether it needs to skip a text leaf child.
This check previously assumed there was a child to check, which crashed for a container with no children.
Differential Revision: https://phabricator.services.mozilla.com/D6588
--HG--
extra : moz-landing-system : lando
The compiler is not smart enough to infer that MOZ_RELEASE_ASSERT(false, ...)
will never return. Using MOZ_CRASH instead.
--HG--
extra : rebase_source : 0791f203592b4edf46a517d7945cf720a197d2da
extra : intermediate-source : 44c07680d016d5d72f77c92d968e647dd8d1b6b9
extra : source : 155877282932ab2678069c9d00672191c655e5b1
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.
Appearently with UA Widget the page loads quicker, so the tests must now
explicitly wait for the audio source to load to test on the video controls
UI in its stable state.
Depends on D3840
Differential Revision: https://phabricator.services.mozilla.com/D3841
--HG--
extra : moz-landing-system : lando
This can easily be reproduced if the ancestor being owned has role="presentation", but there are other cases as well.
If we don't prevent this, we end up with a loop.
Differential Revision: https://phabricator.services.mozilla.com/D4051
--HG--
extra : moz-landing-system : lando
All but one of the current uses of DEFFILE use `SRCDIR + '/file.def'` to
get a srcdir-relative path anyway, and the other one wants an
objdir-relative path, so using Path makes everything clearer.
This makes it more straightforward to translate the paths for the WSL
build.
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
