[Webkit-unassigned] [Bug 100275] Programmatically-inserted children lack accessibility events

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Dec 6 08:30:48 PST 2013


https://bugs.webkit.org/show_bug.cgi?id=100275





--- Comment #15 from Mario Sanchez Prada <mario at webkit.org>  2013-12-06 08:29:05 PST ---
(From update of attachment 218589)
View in context: https://bugs.webkit.org/attachment.cgi?id=218589&action=review

>> Source/WebCore/accessibility/atk/AXObjectCacheAtk.cpp:45
>> +        bomb->updateBackingStore();
> 
> i assume you don't want to add this

Oops! I certainly don't want to add that. Just a quick check with a release build :)

>> Source/WebCore/accessibility/atk/AXObjectCacheAtk.cpp:89
>> +    size_t index = coreParent->children().find(obj);
> 
> you should probably check that index != WTF::notFOund before proceeding and possible assert that condition

The problem with that is that I've observed that sometimes we might get a -1 here (meaning that the object has not been added yet to the children vector of the parent) and in those cases, even if not ideal, we would still like to notify to ATs that the parent AtkObject (which is accessible by navigating the hierarchy anyway) has gained a new children (-1 is a valid value to be emitted along with this signal, as per ATK documentation, when you can't determine the offset at the time of emission).

So, even if I recognise is not a very clean behavior, I think it's better to emit the signal anyway as long as we have an AtkObject for the child and for the parent, even if we can't properly determine the offset sometimes. Perhaps this is something we could try to improve later anyway.

>> Source/WebCore/accessibility/atk/AXObjectCacheAtk.cpp:199
>> +        for (int i = 0; i < atk_object_get_n_accessible_children(axObject); ++i)
> 
> this should be in a var so we don't query each iteration through the run loop
> atk_object_get_n_accessible_children(axObject)

Ok.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list