Bug 125783

Summary: AX: WebKit not sending AXMenuClosed notification
Product: WebKit Reporter: chris fleizach <cfleizach>
Component: AccessibilityAssignee: chris fleizach <cfleizach>
Status: RESOLVED FIXED    
Severity: Normal CC: aboxhall, apinheiro, commit-queue, dmazzoni, jcraig, jdiggs, mario, samuel_white, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
patch mario: review+

Description chris fleizach 2013-12-16 09:17:29 PST
AXMenuClosedNotification
https://dvcs.w3.org/hg/pfwg/raw-file/default/ARIA-UAIG/1.0/tests/test-files/test96.html
Comment 1 chris fleizach 2013-12-16 09:17:42 PST
<rdar://problem/15668928>
Comment 2 chris fleizach 2013-12-18 00:05:23 PST
Created attachment 219510 [details]
patch
Comment 3 Mario Sanchez Prada 2013-12-18 04:03:46 PST
Comment on attachment 219510 [details]
patch

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

> Source/WebCore/accessibility/AccessibilityObject.cpp:95
> +    // Menu close events need to notify the platform. No element is used in the notification because it's a destruction event.
> +    if (detachmentType == ElementDestroyed && roleValue() == MenuRole && cache)
> +        cache->postNotification(nullptr, &cache->document(), AXObjectCache::AXMenuClosed);

Would it be possible to use AccessibilityObject::document() here, so you would not need to add AXObjectCache::document()?

Also, would it be possible to use AccessibilityObject::axObjectCache(), instead of having to add that new first parameter to AccessibilityObject::detach()?

I guess the answer is that it's probably too late here to get the document (and hence the AXObjectCache out of it) from the AccessibilityObject that is being detached, but I have to ask anyway :)

If that's the case, maybe it would be cleaner to swap the arguments in detach() and add a default value for the cache, so we have something like void detach(AccessibilityDetachmentType, AXObjectCache* axObjectCache = nullptr) that allows you to omit that "mysterious" nullptr parameter when not using ElementDestroyed as the "detachment type"
Comment 4 chris fleizach 2013-12-18 05:48:33 PST
(In reply to comment #3)
> (From update of attachment 219510 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=219510&action=review
> 
> > Source/WebCore/accessibility/AccessibilityObject.cpp:95
> > +    // Menu close events need to notify the platform. No element is used in the notification because it's a destruction event.
> > +    if (detachmentType == ElementDestroyed && roleValue() == MenuRole && cache)
> > +        cache->postNotification(nullptr, &cache->document(), AXObjectCache::AXMenuClosed);
> 
> Would it be possible to use AccessibilityObject::document() here, so you would not need to add AXObjectCache::document()?
> 
> Also, would it be possible to use AccessibilityObject::axObjectCache(), instead of having to add that new first parameter to AccessibilityObject::detach()?
> 
> I guess the answer is that it's probably too late here to get the document (and hence the AXObjectCache out of it) from the AccessibilityObject that is being detached, but I have to ask anyway :)

Correct

> 
> If that's the case, maybe it would be cleaner to swap the arguments in detach() and add a default value for the cache, so we have something like void detach(AccessibilityDetachmentType, AXObjectCache* axObjectCache = nullptr) that allows you to omit that "mysterious" nullptr parameter when not using ElementDestroyed as the "detachment type"

Yep. No problem
Comment 5 Mario Sanchez Prada 2013-12-18 07:45:53 PST
Comment on attachment 219510 [details]
patch

(In reply to comment #4)
> [...]
> > If that's the case, maybe it would be cleaner to swap the arguments in detach() and add a default value for the cache, so we have something like void detach(AccessibilityDetachmentType, AXObjectCache* axObjectCache = nullptr) that allows you to omit that "mysterious" nullptr parameter when not using ElementDestroyed as the "detachment type"
> 
> Yep. No problem

Thanks for the confirmation. Setting r+ now
Comment 6 chris fleizach 2013-12-18 10:49:27 PST
https://trac.webkit.org/changeset/160778