Bug 126993 – AX: WebKit is not firing AXMenuOpenedNotification

• Component: Accessibility
• Status: RESOLVED FIXED

[chris fleizach]

WebKit is not firing menu open notification

AXMenuOpenedNotification
https://dvcs.w3.org/hg/pfwg/raw-file/default/ARIA-UAIG/1.0/tests/test-files/test93.html

[chris fleizach]

<rdar://problem/15284928>

[chris fleizach]

Created attachment 221180 [details]
patch

[Mario Sanchez Prada]

Comment on attachment 221180 [details]
patch

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

> Source/WebCore/ChangeLog:29
> +        (WebCore::RenderElement::insertChildInternal):
> +        (WebCore::RenderElement::styleWillChange):

Would it make sense to pass the new child being added in RenderMenuList::addChild too? (probably not)

> Source/WebCore/accessibility/AXObjectCache.cpp:632
> +void AXObjectCache::childrenChanged(Node* node, Node* newChild)
> +{
> +    if (newChild)
> +        checkForOpenMenu(newChild);
>      childrenChanged(get(node));
>  }

I can't see in this patch any usage of this function (using Node pointers as parameters) passing the new parameter 'newChild'.

Maybe it's not needed to add it then? Or perhaps there's a missing bit in the attached patch?

> Source/WebCore/accessibility/AXObjectCache.cpp:688
> +    

Extra blank lines

> Source/WebCore/accessibility/AXObjectCache.h:108
> +    void childrenChanged(Node*, Node* newChild = 0);
> +    void childrenChanged(RenderObject*, RenderObject* newChild = 0);

There was a recent discussion in webkit-dev and I think the agreement was to use nullptr in this cases instead of 0 or NULL (with the exception of Objective-C files)

[chris fleizach]

Created attachment 221284 [details]
patch

[chris fleizach]

http://trac.webkit.org/changeset/162132

[Alexey Proskuryakov]

platform/mac/accessibility/aria-multiline.html has started to sometimes hit assertions today, possibly because of this change. Filed bug 127141.