Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
I don't understand why we don't allow any box through, but for now this
is a safer change to restore the previous behavior when emulated flex
box is used.
Differential Revision: https://phabricator.services.mozilla.com/D158002
Some markup elements expose Accessible attributes which must be retrieved from DOM; e.g. the datetime attribute of the datetime element.
We don't cache these yet for RemoteAccessible.
Previously, these were unintentionally exposed from MarkupAttributes with null values.
For now, these should be skipped instead until we have caching code for them.
This fixes crashes whenever a client tries to fetch attributes from such an element.
Differential Revision: https://phabricator.services.mozilla.com/D151659
RemoteAccessibleBase::Attributes will soon use the service to query markup attributes.
Thus, the service must not shut down while a client call is being handled on the UI thread.
Differential Revision: https://phabricator.services.mozilla.com/D150722
Previously, these methods took a DOM nsIContent, making it impossible for them to work for RemoteAccessible.
GetMarkupMapInfoForNode has been renamed to GetMarkupMapInfoFor and has overloads for nsIContent and Accessible.
MarkupAttribute is a template which can take either, as we still need the nsIContent version elsewhere.
MarkupAttributes now only takes an Accessible, as it can get the nsIContent from the Accessible if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D150377
Previously, these methods took a DOM nsIContent, making it impossible for them to work for RemoteAccessible.
GetMarkupMapInfoForNode has been renamed to GetMarkupMapInfoFor and has overloads for nsIContent and Accessible.
MarkupAttribute is a template which can take either, as we still need the nsIContent version elsewhere.
MarkupAttributes now only takes an Accessible, as it can get the nsIContent from the Accessible if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D150377
This was wasting memory for the parent process, and when the cache was disabled, all content processes.
QueueCacheUpdate now checks whether we are actually sending cache updates before it queues anything.
Simple calls rely on this check, rather than guarding the call to QueueCacheUpdate themselves.
We still call QueueCacheUpdate conditionally for more complex cases which would have to do work before calling QueueCacheUpdate, since we don't want to pointlessly do that prerequisite work.
Differential Revision: https://phabricator.services.mozilla.com/D149231
This change allows us to remove the `FullZoom` multiplier and fixes text
bounds caclulations in a zoomed page.
Testing: The current browser scroll/bounds tests pass (with the
exception of fission iframes which were already broken).
Differential Revision: https://phabricator.services.mozilla.com/D146507
Normally, we treat the body as the DOM node for a DocAccessible.
However, a click listener can be added to the root element; e.g. the html element.
We now treat a click listener added to the root element the same as if one were added to the body.
This required a change to nsAccessibilityService to use the DocAccessible when click listeners change for the root element so a cache update is pushed.
This change was made for the body also, since we weren't pushing a cache update for click listener changes on the body either.
Differential Revision: https://phabricator.services.mozilla.com/D144278
In terms of the C++ code, this patch does basically one thing, which is
allowing creating option / optgroup accessibles without a frame for
comboboxes, and tracking mutations like layout does.
It seems this should be straight-forward, but handling mutations got a
bit complicated. We don't want to forcibly re-create accessibles, so we
want to re-use the PruneOrInsertSubtree logic that ContentInserted uses.
But determining whether we need to create the accessible requires
having flushed styles, so I added a ScheduleAccessibilitySubtreeUpdate
API to trigger that from WillRefresh once style and layout are
up-to-date.
The rest of the test updates should be sort of straight-forward. They
reflect two changes:
* <option> accessibles are leaves now (so they don't have text
children). Note that we still have the right native name and so on,
using the same logic we use to render the label.
* In 1proc tests, the focus no longer goes to the <option>, and uses
the same code-path that e10s does (moving focus to a <menulist> in
the parent process). Since that wasn't easy to test for (afaict) and
we have browser tests to cover that
(browser_treeupdate_select_dropdown.js, etc), I've decided to just
remove the tests that relied on the previous code-path, as they were
testing for a codepath that users weren't hitting anyways.
I've tested this with JAWS and Orca and behavior seems unchanged to my
knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D133098
In terms of the C++ code, this patch does basically one thing, which is
allowing creating option / optgroup accessibles without a frame for
comboboxes, and tracking mutations like layout does.
It seems this should be straight-forward, but handling mutations got a
bit complicated. We don't want to forcibly re-create accessibles, so we
want to re-use the PruneOrInsertSubtree logic that ContentInserted uses.
But determining whether we need to create the accessible requires
having flushed styles, so I added a ScheduleAccessibilitySubtreeUpdate
API to trigger that from WillRefresh once style and layout are
up-to-date.
The rest of the test updates should be sort of straight-forward. They
reflect two changes:
* <option> accessibles are leaves now (so they don't have text
children). Note that we still have the right native name and so on,
using the same logic we use to render the label.
* In 1proc tests, the focus no longer goes to the <option>, and uses
the same code-path that e10s does (moving focus to a <menulist> in
the parent process). Since that wasn't easy to test for (afaict) and
we have browser tests to cover that
(browser_treeupdate_select_dropdown.js, etc), I've decided to just
remove the tests that relied on the previous code-path, as they were
testing for a codepath that users weren't hitting anyways.
I've tested this with JAWS and Orca and behavior seems unchanged to my
knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D133098
Building with --disable-xul has been busted since _at least_ bug
1082579, for more than 7 years (I didn't try to track that down
further). It's time to recognize that the option serves no purpose.
Differential Revision: https://phabricator.services.mozilla.com/D133161
Currently, checking whether an `EventTarget` is `nsINode` (or its concrete
classes) or not requires a QI, but it's expensive and used a lot while we
handle each event. Therefore, it'd be nicer for creating a virtual method,
`EventTarget::IsNode()` and use it for the check.
If trying to convert `EventTarget` to a concrete class, it may require two
virtual method calls. I'm not sure whether it's cheaper than a QI, but at
least, it won't depend on the UUID check order of `QueryInterface()` when
multiple interfaces are implemented.
Differential Revision: https://phabricator.services.mozilla.com/D129781
Use imgINotificationObserver to get notified of size availability.
Layout uses an observer to wait for this too. Our observer is notified
after layout so we should have bounds by then.
We need to store the request status because we get a lot of "replayed"
status changes that would cause chatty and wrong state change events
when the accessible is first created and bound to parent.
We can use that status for both INVISIBLE and ANIMATED states in
NativeState.
Differential Revision: https://phabricator.services.mozilla.com/D127719
Use imgINotificationObserver to get notified of size availability.
Layout uses an observer to wait for this too. Our observer is notified
after layout so we should have bounds by then.
We need to store the request status because we get a lot of "replayed"
status changes that would cause chatty and wrong state change events
when the accessible is first created and bound to parent.
We can use that status for both INVISIBLE and ANIMATED states in
NativeState.
Differential Revision: https://phabricator.services.mozilla.com/D127719
Use imgINotificationObserver to get notified of size availability.
Layout uses an observer to wait for this too. Our observer is notified
after layout so we should have bounds by then.
We need to store the request status because we get a lot of "replayed"
status changes that would cause chatty and wrong state change events
when the accessible is first created and bound to parent.
We can use that status for both INVISIBLE and ANIMATED states in
NativeState.
Differential Revision: https://phabricator.services.mozilla.com/D127719
Needed to tweak tests a bit because the code is now more descerning
wheter to fire an event or not. Will do so only if the state actually
changes.
Depends on D120901
Differential Revision: https://phabricator.services.mozilla.com/D120902
This isn't used and thus isn't necessary.
Also, we can currently only support 127 content processes because of this id allocation, so avoiding this removes that restriction.
Differential Revision: https://phabricator.services.mozilla.com/D116206
In 1513447 there is a demonstrated instance in which the generated
marker is replaced with another one and throws the list item bullet
state into an unknown state. To remedy this we need to observe when such
elements are removed and added.
Instead of that, I opted to finally make the bullet accessible a real
content-backed accessible. This should help with other issues that pop
up when the list item overrides children management and keeps an
artificial accessible as its first child.
Differential Revision: https://phabricator.services.mozilla.com/D110719
