Closed Bug 395902 Opened 14 years ago Closed 13 years ago

children-changed event points to wrong child for lists

Categories

(Core :: Disability Access APIs, defect)

x86
Linux
defect
Not set
blocker

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: scott, Assigned: surkov)

References

(Blocks 2 open bugs)

Details

(Whiteboard: orca:immediate)

Attachments

(1 file)

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.
Blocks: aria, fox3access
Scott, what do the object attributes for posinset and setsize tell you?
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.  
Blocks: orca
Severity: normal → blocker
Whiteboard: orca:immediate
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 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?
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.
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.
Assignee: aaronleventhal → surkov.alexander
(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.
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.
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.
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.
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.
Well that's the best news I've heard in a while!
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.