children-changed event points to wrong child for lists




12 years ago
12 years ago


(Reporter: scott, Assigned: surkov)


(Blocks 2 bugs)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: orca:immediate)


(1 attachment)



12 years ago
The live region test case 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.


12 years ago
Blocks: aria, fox3access

Comment 1

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

Comment 2

12 years ago
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.  


12 years ago
Blocks: orca


12 years ago
Severity: normal → blocker
Whiteboard: orca:immediate

Comment 3

12 years ago
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

12 years ago
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

12 years ago
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

12 years ago
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

Comment 7

12 years ago
(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

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

See this line:

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

12 years ago
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

12 years ago
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

12 years ago
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

12 years ago
Well that's the best news I've heard in a while!
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.