Bug 215613

Summary: Fix for accessibility/mac/aria-expanded-notifications.html in isolated tree mode.
Product: WebKit Reporter: Andres Gonzalez <andresg_22>
Component: New BugsAssignee: Andres Gonzalez <andresg_22>
Status: RESOLVED FIXED    
Severity: Normal CC: aboxhall, 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

Description Andres Gonzalez 2020-08-18 09:30:52 PDT
Fix for accessibility/mac/aria-expanded-notifications.html in isolated tree mode.
Comment 1 Andres Gonzalez 2020-08-18 10:03:41 PDT
Created attachment 406790 [details]
Patch
Comment 2 Darin Adler 2020-08-18 10:38:03 PDT
Comment on attachment 406790 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=406790&action=review

> Source/WebCore/accessibility/AXObjectCache.cpp:1655
> +    if (auto* object = get(node)) {

I’d like to see get return a RefPtr, then we don’t have to do this "protected" thing. But that’s probably a big change.

Another way do it is to write this:

    if (auto object = makeRefPtr(node))

I like that better than using a separate "protectedObject".

> Source/WebCore/accessibility/AXObjectCache.cpp:1656
> +        // This object might be deleted during the call to findAncestor, thus increase its ref count to avoid destruction.

Are you are that’s true? Seems peculiar that findAncestor can do this. How would finding an ancestor have side effects? We’re just calling roleValue. Does that function do non-obvious work?

Seems more likely that postNotification could delete the object. So I guess we probably do need to use RefPtr. But the comment is misleading, I think.

> Source/WebCore/accessibility/AXObjectCache.cpp:1660
> +        auto* ancestor = Accessibility::findAncestor<AccessibilityObject>(*object, false, [] (const auto& obj) {

Please don’t use abbreviations like "obj" in WebKit code. I suggest "candidate" here, but another word would be fine. Also can just be "auto&", no need to state "const".

> Source/WebCore/accessibility/AXObjectCache.cpp:1670
> +            switch (obj.roleValue()) {
> +            case AccessibilityRole::Tree:
> +            case AccessibilityRole::TreeGrid:
> +            case AccessibilityRole::Grid:
> +            case AccessibilityRole::Table:
> +            case AccessibilityRole::Browser:
> +                return true;
> +            default:
> +                return false;
> +            }

Should we have a function called something like supportsRowCountChanged instead of writing out the switch like this?
Comment 3 Andres Gonzalez 2020-08-18 13:07:07 PDT
Created attachment 406801 [details]
Patch
Comment 4 Andres Gonzalez 2020-08-18 13:18:10 PDT
(In reply to Darin Adler from comment #2)
> Comment on attachment 406790 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=406790&action=review
> 
> > Source/WebCore/accessibility/AXObjectCache.cpp:1655
> > +    if (auto* object = get(node)) {
> 
> I’d like to see get return a RefPtr, then we don’t have to do this
> "protected" thing. But that’s probably a big change.
> 
> Another way do it is to write this:
> 
>     if (auto object = makeRefPtr(node))
> 
> I like that better than using a separate "protectedObject".

Yes! fixed.
> 
> > Source/WebCore/accessibility/AXObjectCache.cpp:1656
> > +        // This object might be deleted during the call to findAncestor, thus increase its ref count to avoid destruction.
> 
> Are you are that’s true? Seems peculiar that findAncestor can do this. How
> would finding an ancestor have side effects? We’re just calling roleValue.
> Does that function do non-obvious work?
> 
> Seems more likely that postNotification could delete the object. So I guess
> we probably do need to use RefPtr. But the comment is misleading, I think.

The original comment referred to parentObject since they were using a while loop to traverse the hierarchy upwards instead of findAncestor. I have not confirm that parentObject indeed may cause the object to be deleted, so I trusted whoever wrote that. But the point is kind of mute now that we are using the RefPtr.
> 
> > Source/WebCore/accessibility/AXObjectCache.cpp:1660
> > +        auto* ancestor = Accessibility::findAncestor<AccessibilityObject>(*object, false, [] (const auto& obj) {
> 
> Please don’t use abbreviations like "obj" in WebKit code. I suggest
> "candidate" here, but another word would be fine. Also can just be "auto&",
> no need to state "const".

Fixed.
> 
> > Source/WebCore/accessibility/AXObjectCache.cpp:1670
> > +            switch (obj.roleValue()) {
> > +            case AccessibilityRole::Tree:
> > +            case AccessibilityRole::TreeGrid:
> > +            case AccessibilityRole::Grid:
> > +            case AccessibilityRole::Table:
> > +            case AccessibilityRole::Browser:
> > +                return true;
> > +            default:
> > +                return false;
> > +            }
> 
> Should we have a function called something like supportsRowCountChanged
> instead of writing out the switch like this?

Yes, fixed.
Comment 5 EWS 2020-08-18 17:54:49 PDT
Committed r265842: <https://trac.webkit.org/changeset/265842>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 406801 [details].
Comment 6 Radar WebKit Bug Importer 2020-08-18 17:55:18 PDT
<rdar://problem/67365749>