Closed
Bug 895082
Opened 11 years ago
Closed 11 years ago
"ASSERTION: Adopting child!" in Accessible::BindToParent with multiple <body> elements
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
FIXED
mozilla28
People
(Reporter: jruderman, Assigned: tbsaunde, NeedInfo)
References
(Blocks 1 open bug)
Details
(Keywords: assertion, testcase)
Attachments
(3 files)
No description provided.
|
Reporter | |
Comment 1•11 years ago
|
||
|
Assignee | |
Comment 2•11 years ago
|
||
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?
|
||
Comment 3•11 years ago
|
||
(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?
|
|
Assignee | |
Comment 4•11 years ago
|
||
(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.
|
|
||
Comment 5•11 years ago
|
||
in general body element doesn't have an accessible at all, it doesn't look like in this case it should either
|
|
Assignee | |
Comment 6•11 years ago
|
||
(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?
|
|
||
Comment 7•11 years ago
|
||
(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
|
|
Assignee | |
Comment 8•11 years ago
|
||
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 9•11 years ago
|
||
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+
|
||
Updated•11 years ago
|
Assignee: nobody → trev.saunders
|
|
Assignee | |
Comment 10•11 years ago
|
||
|
||
Comment 11•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
|
||
Comment 12•11 years ago
|
||
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.
Description
•