Bug 232130 - AX: AccessibilityObject::m_haveChildren and AXCoreObject::hasChildren() are misleadingly named
Summary: AX: AccessibilityObject::m_haveChildren and AXCoreObject::hasChildren() are m...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-10-21 20:47 PDT by Tyler Wilcock
Modified: 2021-10-25 10:41 PDT (History)
11 users (show)

See Also:


Attachments
Patch (20.63 KB, patch)
2021-10-21 20:57 PDT, Tyler Wilcock
no flags Details | Formatted Diff | Diff
Patch (20.60 KB, patch)
2021-10-21 22:08 PDT, Tyler Wilcock
no flags Details | Formatted Diff | Diff
Patch (20.83 KB, patch)
2021-10-22 07:41 PDT, Tyler Wilcock
no flags Details | Formatted Diff | Diff
Patch (20.98 KB, patch)
2021-10-24 11:50 PDT, Tyler Wilcock
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tyler Wilcock 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.
Comment 1 Radar WebKit Bug Importer 2021-10-21 20:47:29 PDT
<rdar://problem/84534428>
Comment 2 Tyler Wilcock 2021-10-21 20:57:06 PDT
Created attachment 442112 [details]
Patch
Comment 3 chris fleizach 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
Comment 4 Tyler Wilcock 2021-10-21 22:08:50 PDT
Created attachment 442120 [details]
Patch
Comment 5 Tyler Wilcock 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.
Comment 6 chris fleizach 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
Comment 7 Tyler Wilcock 2021-10-22 07:41:36 PDT
Created attachment 442164 [details]
Patch
Comment 8 Tyler Wilcock 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.
Comment 9 EWS 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.
Comment 10 Tyler Wilcock 2021-10-24 11:50:49 PDT
Created attachment 442314 [details]
Patch
Comment 11 EWS 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].
Comment 12 Andres Gonzalez 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.
Comment 13 Tyler Wilcock 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
Comment 14 Darin Adler 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().
Comment 15 Tyler Wilcock 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.