Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 395902 - children-changed event points to wrong child for lists
: children-changed event points to wrong child for lists
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86 Linux
: -- blocker (vote)
: ---
Assigned To: alexander :surkov
: alexander :surkov
Depends on:
Blocks: aria orca fox3access
  Show dependency treegraph
Reported: 2007-09-12 07:19 PDT by Scott Haeger
Modified: 2007-10-29 11:34 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

test case with no remove (1.07 KB, application/xml)
2007-10-26 20:56 PDT, Scott Haeger
no flags Details

Description Scott Haeger 2007-09-12 07:19:33 PDT
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.
Comment 1 Aaron Leventhal 2007-09-28 13:34:25 PDT
Scott, what do the object attributes for posinset and setsize tell you?
Comment 2 Scott Haeger 2007-09-28 14:30:14 PDT
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 2007-10-06 08:28:03 PDT
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 2007-10-26 07:36:09 PDT
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 2007-10-26 07:43:52 PDT
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 2007-10-26 08:12:25 PDT
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 2007-10-26 19:37:37 PDT
(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 2007-10-26 20:00:56 PDT
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 Aaron Leventhal 2007-10-26 20:01:38 PDT
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 2007-10-26 20:56:29 PDT
Created attachment 286375 [details]
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 2007-10-29 11:14:07 PDT
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 2007-10-29 11:34:37 PDT
Well that's the best news I've heard in a while!

Note You need to log in before you can comment on or make changes to this bug.