Looks like *aContainerAccessible is being used without being checked for not NSNULL first. May there be situations where aContainerAccessible may be NULL? Should there be a check here?
Not enough info to block.  Would take a patch.
Marco, let's put an assertion and not call CreateTextChangeEventForNode though it's suspicious GetAccessibleInParentChain return nsnull.
Should we put that logic into GetAccessibleInParentChain() ... basically make sure it never returns null and returns the doc accessible if necessary?
> sure it never returns null and returns the doc accessible if necessary?
> > sure it never returns null and returns the doc accessible if necessary?
Aaron, GetAccessibleInParentChain() is used in many places and nsnull result is processed in different ways. I wouldn't risk to change this in the meantime. So if you fine with this then let's save the current approach.
Attachment #316545 - Flags: approval1.9?
Ok, thank you for looking at it anyway.
Possible to test?  re-request approval once addressed.
> Possible to test?  re-request approval once addressed.
We haven't a way to reproduce the bug. We just have stack trace. I tried to do small changes I can. If the test is major condition for the current status of the tree then let's wait for 1.9.x to land this trying of the the crash fix.
Attachment #316545 - Flags: approval1.9- → approval1.9?
What's the regression risk?  Sorry to keep asking this, but we need to be extra extra careful right now.  Re-nom when answered.
> extra careful right now.  Re-nom when answered.
Since we get a notification from layout module and we don't get which element has been changed then we must invalidate the document entirely. Here we do this by sending corresponding events to accessible for document node. I think the risk is minimal, it doesn't bring major changes.