The reason is when we get STATE_START state flag in OnStateChange the document is not ready. We always get some HTML document from nsIWebProgress object (even if chrome XUL document is loaded) which is not accessible. I suspect this is kind of stub. I suggest to pend document creation and document load start event and listen to STATE_TRANSFERRING state. When we are notified of this state then the document is created, so we are safe to create document accessible. The problem of state tranfsering is it's not always fired for XUL documents. Here we get STATE_START state and then STATE_STOP state with failure status. I think we can figure out what's wrong later.

The wrong document problem on STATE_START was discussed in bug 417249 and we have open bug 419626 for this. However we don't fire start/end load document events in nsDocAccessible::FireDocLoadEvent for frame/iframe documents starting from checkin http://hg.mozilla.org/mozilla-central/rev/c516d78f90fd (which was supposed to fix bug 417249, bug 417578, bug 405951, bug 413778, bug 412878). I still don't get a reason.

The reason is "Fire show/hide events to indicate frame/iframe content is new, rather than doc load event which causes screen readers to act is if entire page is reloaded".

fixed by 566103. We don't want document start event any more since we stopped to use it internally and there's no analogy in AT.