Closed Bug 1879255 Opened 6 months ago Closed 5 months ago

Support Element.popoverTargetElement in the a11y engine


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




125 Branch
Tracking Status
firefox125 --- fixed


(Reporter: Jamie, Assigned: Jamie)


(Blocks 2 open bugs)



(3 files)

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.

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.

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.

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.

Attachment #9379838 - Attachment description: Bug 1879255 part 1: Add Element::GetExplicitAttrElement. → Bug 1879255 part 1: Add Element::GetExplicitlySetAttrElement.
Pushed by
part 1: Add Element::GetExplicitlySetAttrElement. r=smaug
part 2: Add a dependent elements map to DocAccessible and use it for popoverTargetElement. r=morgan
part 3: Notify accessibility about changes to explicitly set attr-elements. r=smaug,eeejay
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 125 Branch
You need to log in before you can comment on or make changes to this bug.