359784 - preferences pane accessible tree uncomplete

Status: RESOLVED FIXED

(Firefox :: Disability Access, defect)

Description

[Nian Liu(n/a in a long time)]

1.run trunk nightly build
2.open edit->preferences, click on different tab
3.use at-poke to poke

only part of accessible content shows in at-poke. and the part content shows is very unstable which means sometimes this part, and sometimes another part.

Comment 1

[Nian Liu(n/a in a long time)]

more like an at-poke bug. when switch among tabs, accessible objects are created. however, at-poke doesn't show them

Comment 2

[Nian Liu(n/a in a long time)]

(In reply to comment #1)
> more like an at-poke bug. when switch among tabs, accessible objects are
> created. however, at-poke doesn't show them
> 

forgot this. a firefox bug. 1.8.1branch works fine

Comment 3

[Nian Liu(n/a in a long time)]

children:changed:add was not sent.

getcachedparent returns null cause that.

Comment 4

[Nian Liu(n/a in a long time)]

Attachment: patch

parent hasn't been cached when invalide is called. so use getParent to replace getCachedParent

Comment 5

[Nian Liu(n/a in a long time)]

Attachment: patch

regression of 348158

nsAccessible::GetParent not work for prefpane "tabs"
nsnsDocAccessible::GetAccessibleInParentChain works for all prefpane.

seems we have a bug in nsAccessible::GetParent?

Aaron, what do you think?

Comment 6

[Aaron Leventhal]

Comment on attachment 245545 [details] [diff] [review]
patch

I think the patch won't cause any problems, but I'm not 100% sure. It will end up creating parents sometimes for nodes that are going away.

But, I don't understand your question:
> nsAccessible::GetParent not work for prefpane "tabs"
> seems we have a bug in nsAccessible::GetParent?

Do you mean GetCachedParent() ? Or, what bug is there in GetParent() and how does that affect this?

The problem with GetCachedParent() is clearly that if the parent had not previously been created then nothing will be returned.

Comment 7

[Nian Liu(n/a in a long time)]

> But, I don't understand your question:
> > nsAccessible::GetParent not work for prefpane "tabs"
> > seems we have a bug in nsAccessible::GetParent?
if we use GetParent, no children-changed:add fires for prefpane "tabs", for others prefpane, it fires correctlly. 

GetAccessibleInParentChain works fine for all prefpane. so i wonder our implementation of GetParent may have a bug

Comment 8

[Aaron Leventhal]

Do you mean GetCachedParent() ?

We never used GetParent().

And if GetParent() has a bug then GetAccessibleInParentChain() would have one too.

Comment 9

[Nian Liu(n/a in a long time)]

(In reply to comment #8)
> Do you mean GetCachedParent() ?
> 
> We never used GetParent().
> 
> And if GetParent() has a bug then GetAccessibleInParentChain() would have one
> too.
> 

(In reply to comment #8)
> Do you mean GetCachedParent() ?
> 
> We never used GetParent().
> 
> And if GetParent() has a bug then GetAccessibleInParentChain() would have one
> too.
> 

GetCachedParent doesn't work due to no parenet cached before it's called. so i use GetParent to replace GetCachedParent and found almost all panes works fine except "tabs" pane. then i used GetAccessibleInParentChain to replace GetParent and every panes works fine.

so my conclusion is that we have a bug in GetParent.

i checked the implementation of each functions. they use different ways.

Comment 10

[Aaron Leventhal]

You're right, GetAccessibleInParentChain checks the DOM parent chain for accessibles.

For a bug like this, you'll have to come up with a very small testcase to find the problem.

So, where do we stand on getting this done? You have r+. Why not check it in and file a separate bug for the  GetParent() issue?

Comment 11

[Ginn Chen]

committed