textareas contain an anonymous div which fires the scroll event.
We don't have an Accessible for this div, so previously, we were just ignoring the scroll event.
Now, we'll redirect it to the textarea and get its Accessible.
This ensures that we push a cache update so that the scroll position (and thus the bounds) are correct.
This also means that a11y scroll events are fired on textareas where they weren't previously.
Differential Revision: https://phabricator.services.mozilla.com/D166508
Transition the group position calculation - specifically the code in Update -
to Pivot such that we can handle finding siblings across intervening generic
container accessibles, such as SECTIONs. This fixes issues with finding the
values of "pos in set" and "set size" for descendant owned elements in compound
ARIA widgets. This revision also updates and adds tests for this functionality.
Differential Revision: https://phabricator.services.mozilla.com/D165756
These MathML table elements may not have a table display style, in which case
they shouldn't be HTML table accessibles. This revision changes the logic of
MathMLMarkupMap such that mtable, mtr elements create generic ARIA accessibles
if the display style for the element is something other than 'table'. This
revision also adds a test to verify that the roles are still reported correctly,
even with this change.
Differential Revision: https://phabricator.services.mozilla.com/D165980
When an element's slot changes and the element is unslotted, we remove its Accessible.
If the body is moved inside a shadow host at the same time, we will process the slot removal first because moves are processed async.
Previously, this caused us to try to remove the DocAccessible (since it was still associated with the body), causing nastiness and potentially crashes.
We should never try to remove the DocAccessible, so explicitly prevent this when handling slot changes.
An assertion was also added to make sure we never try to remove the DocAccessible in future.
Differential Revision: https://phabricator.services.mozilla.com/D166134
This test passes on automation, somehow, probably due to timing.
Locally the click rolls up the popup (so you'd need a second click to
show the other popup).
This happens both with and without the patch, and given I debugged and
it is trivial to fix, well, make sure to hide the previously open menu
before clicking on another...
Differential Revision: https://phabricator.services.mozilla.com/D165983
Move most the event handling stuff to the DOM. I've left nsMenuBarFrame
for now, but I will be removing that in the future.
The basic set up is:
* nsMenuParent becomes XULMenuParentElement (menubar or popup, manages
the current active menu item)
* nsMenuFrame -> XULButtonElements that return true for IsMenu().
Can't use XULMenuElement because of <button type=menu>, which
behaves like a, well, menu.
This makes the a11y events for menus (DOMMenuItem{Active,Inactive}) make
sense (before that we were firing duplicate Inactive events etc, and the
event order was rather suspicious).
Differential Revision: https://phabricator.services.mozilla.com/D164210
Move most the event handling stuff to the DOM. I've left nsMenuBarFrame
for now, but I will be removing that in the future.
The basic set up is:
* nsMenuParent becomes XULMenuParentElement (menubar or popup, manages
the current active menu item)
* nsMenuFrame -> XULButtonElements that return true for IsMenu().
Can't use XULMenuElement because of <button type=menu>, which
behaves like a, well, menu.
This makes the a11y events for menus (DOMMenuItem{Active,Inactive}) make
sense (before that we were firing duplicate Inactive events etc, and the
event order was rather suspicious).
Differential Revision: https://phabricator.services.mozilla.com/D164210
HTMLSelectEventListener changes are needed, since currently that code works somewhat by accident given that
mTime often contains totally bogus values, like PR_IntervalNow(). Those changes then reveal issues also in
browser_editAddressDialog.js.
Differential Revision: https://phabricator.services.mozilla.com/D165618
My patch in bug 1805414 makes this fail in a way that's perma, and it
seems it is because we're not waiting for the actual value change to
happen.
Differential Revision: https://phabricator.services.mozilla.com/D165238
If the slot attribute is changed to assign the element to a slot which doesn't exist in the shadow DOM, the element is now unslotted and thus shouldn't be rendered.
We have code in PruneOrInsertSubtree to handle changes like this, but that only works if the frame for the shadow host or something inside the shadow DOM gets reconstructed.
In the case of a shadow host with a single child, there might not necessarily be any frame reconstruction.
To handle this, we listen for changes to the slot attribute.
We check if the element is still part of the flat tree (i.e. it is slotted).
If it isn't, we remove its Accessible.
Differential Revision: https://phabricator.services.mozilla.com/D165135
Certain MathML elements such as annotation and annotation-xml don't normally get an Accessible.
However, we force create Accessibles in some cases; e.g. if the element is focusable.
When this happens for these MathML elements (e.g. annotation-xml with a tabindex), we previously created AccessibleWraps which don't support text.
This meant that text formatting information was unavailable and caused assertions when pushing the cache.
To fix this, use HyperTextAccessibleWrap instead.
As a drive-by fix, also use HyperTextAccessibleWrap instead of HyperTextAccessible for content MathML elements.
This was almost certainly a typo when this was implemented.
This wouldn't have been noticeable in tests and some native platforms, but some platforms (e.g. Mac and Windows) do have some overrides in HyperTextAccessibleWrap, so we should use those.
Differential Revision: https://phabricator.services.mozilla.com/D165252
When applying an ancestor transform, ApplyTransform is supplied with the cumulative bounds calculated so far; i.e. from descendants.
When removing the parent relative offset, the code previously set the top left to (0, 0).
This not only removed the parent relative offset, but also the cumulative offset calculated for all descendants!
Instead, we now pass in the cumulative bounds as well as the parent relative bounds.
We only subtract the parent relative bounds.
Differential Revision: https://phabricator.services.mozilla.com/D164995
When applying an ancestor transform, ApplyTransform is supplied with the cumulative bounds calculated so far; i.e. from descendants.
When removing the parent relative offset, the code previously set the top left to (0, 0).
This not only removed the parent relative offset, but also the cumulative offset calculated for all descendants!
Instead, we now pass in the cumulative bounds as well as the parent relative bounds.
We only subtract the parent relative bounds.
Differential Revision: https://phabricator.services.mozilla.com/D164995
Previously, this test case caused an assertion, but that was fixed in bug 1792120.
We also ensure the x and y are the same before an dafter the re-creation.
This verifies that we aren't losing the iframe's border/padding.
Differential Revision: https://phabricator.services.mozilla.com/D164879
Aside from making the code consistent for OOP and in-process iframes, this also fixes incorrect bounds in in-process iframe documents when the iframe's padding is changed.
We always pushed a cache update for the iframe when the padding was changed.
However, we previously relied on parent-relative bounds for in-process iframes, which didn't get updated when the iframe's padding changed.
Differential Revision: https://phabricator.services.mozilla.com/D164878
We previously thought that DocAccessible::GetFrame didn't return a frame.
On the contrary, it has returned the PresShell's root frame for a long time now, which is precisely what we want.
This means we can make this method a bit cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D164877
See the code comments for an explanation.
This fixes assertions and crashes when pushing the cache when a page contains a map which is unslotted in a shadow host.
Differential Revision: https://phabricator.services.mozilla.com/D164783
Calling GetAccessibleOrContainer meant that if a particular content node didn't have an Accessible but did have a frame, we'd insert its container in its place.
There might have been other descendants of that container that did have Accessibles, though.
In that case, we would have put the container ahead of some of its descendants!
To fix this, use GetAccessible instead.
We'll still fall back to the container if the user hit tests a point in an inaccessible node, since it will appear later in the viewport cache.
Differential Revision: https://phabricator.services.mozilla.com/D164803
That patch was always somewhat hacky, but we couldn't figure out the cause of the problem.
Now that I've figured it out, a more correct solution is forthcoming.
Differential Revision: https://phabricator.services.mozilla.com/D164802
As of the prior patch, these are no longer needed. I removed
these with a script, then ran clang-format on the files, then
manually reverted a few unrelated changed from the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D164829
These can contain <foreignobject>, which contains HTML but does not normally create its own Accessible.
This means that these Accessibles could have TextLeafAccessible children.
TextLeafAccessible children must always have a HyperTextAccessible as a parent.
Therefore, we must use HyperTextAccessible for <svg> and <g>.
As well as fixing assertions, this allows text formatting to be queried for <foreignobject> content, which was previously broken.
Differential Revision: https://phabricator.services.mozilla.com/D164636
Morgan Rae Reschenberg
James Teh
Cosmin Sabou
Sandor Molnar
Nathan LaPre
Eitan Isaacson
Ben Freist
Emilio Cobos Álvarez
Csoregi Natalia
Gijs Kruitbosch
Olli Pettay
Sylvestre Ledru
Marco Castelluccio
Mark Banner
Stanca Serban
Andrew McCreight
Norisz Fay
lyavor