Closed Bug 895082 Opened 7 years ago Closed 6 years ago

"ASSERTION: Adopting child!" in Accessible::BindToParent with multiple <body> elements

Categories

(Core :: Disability Access APIs, defect)

x86_64
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla28

People

(Reporter: jruderman, Assigned: tbsaunde, NeedInfo)

References

(Blocks 2 open bugs)

Details

(Keywords: assertion, testcase)

Attachments

(3 files)

Attached file testcase
No description provided.
Attached file stack
So, what happens is this in ProcessContentInserted() we handle the insertion of the new body.
First we set the documents mContent to the new body because it comes first.
Next we call UpdateChildren() on the document, which means InvalidateChildren() is called and the accessibles for the divs become hanging with  no accessible having them as kids.
CacheChildren() on the document doesn't do anything about them, it just creates accessible for old body because it isn't in the document any more.
UpdateTree() is called on the doc with aChildNode being the new body so it does nothing.

Thoughts on how to fix?
(In reply to Trevor Saunders (:tbsaunde) from comment #2)

> CacheChildren() on the document doesn't do anything about them, 

not evident why?

> it just
> creates accessible for old body because it isn't in the document any more.

body is no accessible and it still in document, no? Is refresh triggers after script's setTimeout?
(In reply to alexander :surkov from comment #3)
> (In reply to Trevor Saunders (:tbsaunde) from comment #2)
> 
> > CacheChildren() on the document doesn't do anything about them, 
> 
> not evident why?

because if found accessible for old body and made that child of document, so accessibles for divs that are kids of old body should be children of the accessible for the old body, not the document.

> > it just
> > creates accessible for old body because it isn't in the document any more.
> 
> body is no accessible and it still in document, no? Is refresh triggers
> after script's setTimeout?

new body doesn't get accessible seperet from document accessible, but old body gets an accessible of its own.  I believe WillRefresh() happens before setTimeout.
in general body element doesn't have an accessible at all, it doesn't look like in this case it should either
(In reply to alexander :surkov from comment #5)
> in general body element doesn't have an accessible at all, it doesn't look
> like in this case it should either

so reject accessible for body and gett accesisble children of it as direct child?
(In reply to Trevor Saunders (:tbsaunde) from comment #6)
> (In reply to alexander :surkov from comment #5)
> > in general body element doesn't have an accessible at all, it doesn't look
> > like in this case it should either
> 
> so reject accessible for body and gett accesisble children of it as direct
> child?

do we really have accessible for body in this case? usually GetOrCreateAccessible returns null for body so it's just skipped and all accesisble children under body are children of document
So it turns out nsBlockFrame::AccessibleType() returns eHyperTextType for non primary body elements.  That means the old body in the test case gets a hypertext accessible from CreateAccessibleByframeType().  In this case we can prevent the accessibles for children of the old body from staying hanging by caching the children of the body which is most easily done by recursively caching the children of the container.
Attachment #825461 - Flags: review?(surkov.alexander)
Comment on attachment 825461 [details] [diff] [review]
bug 895082 - recursively cache children in DocAccessible::ProcessContentInserted()

Review of attachment 825461 [details] [diff] [review]:
-----------------------------------------------------------------

please add a comment similar to what you commented in bugzilla
Attachment #825461 - Flags: review?(surkov.alexander) → review+
Assignee: nobody → trev.saunders
https://hg.mozilla.org/mozilla-central/rev/a917c05419f8
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Keywords: verifyme
Couldn't reproduce this on Mac OS X 10.9 with a pre-fix build.

What type of build did you reproduce this with (what options was it built with, if you built it)?
Flags: needinfo?(jruderman)
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.