Bug 232130

Summary: AX: AccessibilityObject::m_haveChildren and AXCoreObject::hasChildren() are misleadingly named
Product: WebKit Reporter: Tyler Wilcock <tyler_w>
Component: AccessibilityAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: aboxhall, andresg_22, apinheiro, cfleizach, darin, dmazzoni, ews-watchlist, jcraig, jdiggs, samuel_white, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch none

Tyler Wilcock
Reported 2021-10-21 20:47:20 PDT
The names of both AccessibilityObject::m_haveChildren and AXCoreObect::hasChildren() imply that the given object has children, i.e. has one or more children. However, what these really mean is whether the object has tried to initialize its children. Both m_haveChildren and hasChildren() can be true for objects that have no children, which is confusing.
Attachments
Patch (20.63 KB, patch)
2021-10-21 20:57 PDT, Tyler Wilcock
no flags
Patch (20.60 KB, patch)
2021-10-21 22:08 PDT, Tyler Wilcock
no flags
Patch (20.83 KB, patch)
2021-10-22 07:41 PDT, Tyler Wilcock
no flags
Patch (20.98 KB, patch)
2021-10-24 11:50 PDT, Tyler Wilcock
no flags
Radar WebKit Bug Importer
Comment 1 2021-10-21 20:47:29 PDT
Tyler Wilcock
Comment 2 2021-10-21 20:57:06 PDT
chris fleizach
Comment 3 2021-10-21 21:14:51 PDT
Comment on attachment 442112 [details] Patch Do we need to actually store this value for isolated tree mode? Seems like we can just return true for this since it would always be initialized
Tyler Wilcock
Comment 4 2021-10-21 22:08:50 PDT
Tyler Wilcock
Comment 5 2021-10-21 22:11:14 PDT
(In reply to chris fleizach from comment #3) > Comment on attachment 442112 [details] > Patch > > Do we need to actually store this value for isolated tree mode? Seems like > we can just return true for this since it would always be initialized Good call, I just looked into it and I don't think we do. Uploaded a new patch.
chris fleizach
Comment 6 2021-10-21 22:40:06 PDT
Comment on attachment 442120 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=442120&action=review > Source/WebCore/accessibility/AccessibilityRenderObject.cpp:3493 > + if (role == AccessibilityRole::SVGRoot && !childrenInitialized()) this looks like an incorrect usage due to poor naming. I think we want to return role is Image if it doesn't have children, not that it wasn't initialized
Tyler Wilcock
Comment 7 2021-10-22 07:41:36 PDT
Tyler Wilcock
Comment 8 2021-10-22 07:42:03 PDT
(In reply to chris fleizach from comment #6) > Comment on attachment 442120 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=442120&action=review > > > Source/WebCore/accessibility/AccessibilityRenderObject.cpp:3493 > > + if (role == AccessibilityRole::SVGRoot && !childrenInitialized()) > > this looks like an incorrect usage due to poor naming. I think we want to > return role is Image if it doesn't have children, not that it wasn't > initialized Agreed — fixed with newest patch.
EWS
Comment 9 2021-10-22 15:56:53 PDT
Tools/Scripts/svn-apply failed to apply attachment 442164 [details] to trunk. Please resolve the conflicts and upload a new patch.
Tyler Wilcock
Comment 10 2021-10-24 11:50:49 PDT
EWS
Comment 11 2021-10-24 15:28:44 PDT
Committed r284769 (243478@main): <https://commits.webkit.org/243478@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 442314 [details].
Andres Gonzalez
Comment 12 2021-10-25 06:47:25 PDT
(In reply to Tyler Wilcock from comment #10) > Created attachment 442314 [details] > Patch --- a/Source/WebCore/accessibility/AccessibilitySpinButton.cpp +++ a/Source/WebCore/accessibility/AccessibilitySpinButton.cpp @@ -45,9 +45,9 @@ AccessibilitySpinButton::~AccessibilitySpinButton() = default; AXCoreObject* AccessibilitySpinButton::incrementButton() { - if (!m_haveChildren) + if (!m_childrenInitialized) addChildren(); - if (!m_haveChildren) + if (!m_childrenInitialized) return nullptr; Does this second check for m_childrenInitialized even make sense? Since addChildren should set it to true by definition. Same for AccessibilitySpinButton::decrementButton.
Tyler Wilcock
Comment 13 2021-10-25 07:21:18 PDT
(In reply to Andres Gonzalez from comment #12) > (In reply to Tyler Wilcock from comment #10) > > Created attachment 442314 [details] > > Patch > > --- a/Source/WebCore/accessibility/AccessibilitySpinButton.cpp > +++ a/Source/WebCore/accessibility/AccessibilitySpinButton.cpp > @@ -45,9 +45,9 @@ AccessibilitySpinButton::~AccessibilitySpinButton() = > default; > > AXCoreObject* AccessibilitySpinButton::incrementButton() > { > - if (!m_haveChildren) > + if (!m_childrenInitialized) > addChildren(); > - if (!m_haveChildren) > + if (!m_childrenInitialized) > return nullptr; > > Does this second check for m_childrenInitialized even make sense? Since > addChildren should set it to true by definition. > > Same for AccessibilitySpinButton::decrementButton. Seems like this guards against the case where a caller used `incrementButton` without a cache active. void AccessibilitySpinButton::addChildren() { AXObjectCache* cache = axObjectCache(); if (!cache) return; m_childrenInitialized = true; ... } This extra check was introduced by this bug: https://bugs.webkit.org/show_bug.cgi?id=157830
Darin Adler
Comment 14 2021-10-25 10:37:01 PDT
Renaming is a good idea. I notice that the name childrenInitialized() is ambiguous. Could be the name for function that is called when children are initialized, not necessarily a predicate that answers the question of whether the children are initialized. This ambiguity is why Cocoa naming encourages names like areChildrenInitialized().
Tyler Wilcock
Comment 15 2021-10-25 10:41:33 PDT
(In reply to Darin Adler from comment #14) > Renaming is a good idea. > > I notice that the name childrenInitialized() is ambiguous. Could be the name > for function that is called when children are initialized, not necessarily a > predicate that answers the question of whether the children are initialized. > This ambiguity is why Cocoa naming encourages names like > areChildrenInitialized(). Yeah, fair point. areChildrenInitialized() makes sense to me. I can create a follow-up patch.
Note You need to log in before you can comment on or make changes to this bug.