Permalink
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Ignore <option> element while building accessibility tree when <selec…
…t> is hidden https://bugs.webkit.org/show_bug.cgi?id=245578 Reviewed by Carlos Garcia Campos. When we insert `AccessibilityObject`'s child, we check that its `parentObject` is the `AccessiblityObject` we're inserting it into. In normal circumstances `AccessibilityObject`'s subclass representing `HTMLSelectElement` is `AccessibilityMenuList`. It creates `AccessiblityMenuListPopup` as its only accessibility child. All `HTMLSelectElement`'s node children accessibility objects are inserted into the popup. For non-multiple `HTMLSelectElement` the only possible node child class that participates in accessibility tree is `HTMLOptionElement` with its accessibility counterpart `AccessibilityMenuListOption`. `AccessibilityMenuListOption`'s `parentObject` is set explicitly to `AccessiblityMenuListPopup` when it's being inserted into one. Situation changes when `HTMLSelectElement` is hidden but `aria-hidden` attribute set to `false` (like in `accessibility/aria-visible-element-roles.html` layout test). In this case, we don't have a renderer object associated with `HTMLSelectElement` and simply create a regular `AccessiblityNodeObject` for it. Then we insert `AccessibilityMenuListOption` as `AccessiblityNodeObject`'s child without setting its `parentObject`. Thus, `child->parentObject() == this` assertion fails. Since we can't present a menu without `HTMLSelectElement`'s renderer anyway (and this is what Chromium does), it's safe to skip `HTMLSelectElement` while building the accessibility tree in such cases. * Source/WebCore/accessibility/AXObjectCache.cpp: (WebCore::AXObjectCache::getOrCreate): Canonical link: https://commits.webkit.org/254970@main
- Loading branch information