395902 - children-changed event points to wrong child for lists

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Scott Haeger]

The live region test case http://accessibleajax.clcworld.net/ajax_chat/chat.htm is an example where an object:children-changed:add event points to the wrong child.  In this case, the add event always points to the 0th child (top of list) instead of the last child which is the new message.  

I suspect object:children-changed:remove is also incorrect.  However, this test case does not demonstrate this because the child that is removed is always the first child.  It would be interesting to test if removing any other child would result in the correct event source.

Comment 1

[Aaron Leventhal]

Scott, what do the object attributes for posinset and setsize tell you?

Comment 2

[Scott Haeger]

I am seeing very different behavior than what I witnessed on 9-12.  Now I cannot create the target object from an object:children-changed:add:system event.

posinset and setsize are sometimes shown for the listitems and other times they are absent.

I have also had a few desktop lockups using Accerciser to view this page, but rarely with other pages including other live region examples.  

Comment 3

[Scott Haeger]

After examining the event details, which seem correct, I suspect that any_data.value() is is pointing to the list-item (the target of the children-changed event) that was just removed.

Comment 4

[Aaron Leventhal]

Comment 2 is talking about added children and comment 3 is talking about remove children, correct? So comment 3 isn't really referring to comment 2?

Comment 5

[Scott Haeger]

I am only looking at object:children-changed:add events right now so all comments refer to these type of events.  My comments in #3 were just speculation as to why we may have the problem and in no way refer to object:children-changed:remove events.

Comment 6

[Aaron Leventhal]

Surkov, do you have a working Ubuntu that you can try this on? I'm having problems with mine right now. Also, I think your patch for bug 398021 night fix it.

Comment 7

[alexander :surkov (:asurkov)]

(In reply to comment #6)
> Surkov, do you have a working Ubuntu that you can try this on? I'm having
> problems with mine right now. Also, I think your patch for bug 398021 night fix
> it.
> 

Unfortunately I have not working Ubuntu now. When I upgraded my computer to 64bit platform then my Ubuntu died. I quieried new version but I didn't get it yet. I guess I can try to reproduce this on windows because there is no very special on linux side.

Comment 8

[Aaron Leventhal]

Surkov, there is a major difference on the Linux side -- the AT-SPI client gets the events asynchronously.

See this line:
http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#1648

I think that's in fact what's biting us. Children changed events on Linux are fired on the parent, with a child index. Then the ATK bridge figures out which ATK object that is for. Since it's asynch, things have probably changed by the time the ATK bridge figures out what the object is.

This could especially happen if you hide something from the top of a list and show something at the bottom of a list at the same time. Perhaps the bug would go away if things were only added to the list.

Comment 9

[Aaron Leventhal]

Scott, can you make a test case where the list items are only ever added to the bottom, and not removed? I have a hunch that the bug will go away then.

Comment 10

[Scott Haeger]

Attachment: test case with no remove

Test case that just adds to a list.  I adapted from Charles's chat example and believe the markup is not completely up to date.  You might want to check it out with respect to the ARIA namespaces.  

This test case does not fix the problem.

Comment 11

[Scott Haeger]

I have now migrated my live region code over to pyatspi to match the rest of Orca and I no longer see the problem.  I can only speculate that Orca had some sort of cache issue related to these event types.

Comment 12

[Aaron Leventhal]

Well that's the best news I've heard in a while!