1879255 - Support Element.popoverTargetElement in the a11y engine

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P1)

Description

[James Teh [:Jamie]]

Bug 1867811 and bug 1870783 add a11y engine support for popover. However, this only supports popover targets set as string ids via the popovertarget content attribute. We also need to support elements set explicitly using the Element.popoverTargetElement WebIDL attribute. The framework for this will also be the groundwork for ARIA element reflection.

Comment 1

[James Teh [:Jamie]]

Attachment: Bug 1879255 part 1: Add Element::GetExplicitlySetAttrElement.

This will be needed by accessibility for two reasons:

1. Accessibility will need to keep track of explicitly set attr-elements even if they aren't a descendant of any of the refering element's shadow-including ancestors. Accessibility will enforce that restriction itself before using the attr-element.
2. Accessibility will need to be able to distinguish between an attr-associated element obtained from an explicitly set attr-element vs derived using an id string in the content attribute. There are other ways to do this, but they are somewhat ugly.

Comment 2

[James Teh [:Jamie]]

Attachment: Bug 1879255 part 2: Add a dependent elements map to DocAccessible and use it for popoverTargetElement.

As well as getting an invoker's popover target, we need to be able to do the reverse: get a popover's invokers.
We can already do this when the popovertarget content attribute is set to a string id using the dependent ids map.
However, the popover target can also be explicitly set to a DOM element using the .popoverTargetElement WebIDL attribute.
For this, we need a new map which maps from target elements instead of target ids.
RelatedAccIterator has also been updated to use this map.
DocAccessible::QueueCacheUpdateForDependentRelations had to be updated as well.
Rather than duplicating logic, RelatedAccIterator has been taught how to optionally return all relations and QueueCacheUpdateForDependentRelations now uses RelatedAccIterator.

Comment 3

[James Teh [:Jamie]]

Attachment: Bug 1879255 part 3: Notify accessibility about changes to explicitly set attr-elements.

Accessibility needs to keep track of changes to explicitly set attr-elements.
Since the popovertarget content attribute is "" for any explicitly set attr-element, we won't always get attribute change notifications for the content attribute when .popoverTargetElement is set.
For example, if e1's popovertarget content attribute is absent and you set e1.popoverTargetElement to e2, the popovertarget content attribute will be "".
If you later set e1.popoverTargetElement to e3, there won't be a notification for the content attribute change, since it remains "".
Even if there were, it would occur after the element has already changed, which means we can't detect any relevant state changes there; e.g. mPrevStateBits.
To deal with this, we now have DOM notify accessibility before and after the explicitly set attr-element is changed.
Within DocAccessible, this is treated like any other attribute change, but the notification methods get called consistently and at the appropriate time.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f52e302f5521
part 1: Add Element::GetExplicitlySetAttrElement. r=smaug
https://hg.mozilla.org/integration/autoland/rev/a43b71e36eb3
part 2: Add a dependent elements map to DocAccessible and use it for popoverTargetElement. r=morgan
https://hg.mozilla.org/integration/autoland/rev/0bc93a4fd2fa
part 3: Notify accessibility about changes to explicitly set attr-elements. r=smaug,eeejay

Comment 5

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/f52e302f5521
https://hg.mozilla.org/mozilla-central/rev/a43b71e36eb3
https://hg.mozilla.org/mozilla-central/rev/0bc93a4fd2fa