Jesse Ruderman Reporter
	Description • 11 years ago

      No description provided.

	Trevor Saunders (:tbsaunde) 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?

	alexander :surkov (:asurkov)
	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?

	Trevor Saunders (:tbsaunde) 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.

	alexander :surkov (:asurkov)
	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

	Trevor Saunders (:tbsaunde) 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?

	alexander :surkov (:asurkov)
	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

	Trevor Saunders (:tbsaunde) 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.

	alexander :surkov (:asurkov)
	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

	Trevor Saunders (:tbsaunde) Assignee
	Comment 10 • 11 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/a917c05419f8

	Carsten Book [:Tomcat]
	Comment 11 • 11 years ago

https://hg.mozilla.org/mozilla-central/rev/a917c05419f8

	Ioana (away)
	Comment 12 • 10 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)?