In the past page load errors brought up a modal dialog, which was accessible with a screen reader. After the checkin for bug 282050, these became "XUL error pages". There is notification sent to a screen reader that these error pages are ready to read, because the typical web progress listener STATE_STOP event does not occur for them.

Things are breaking because of the PageHide event that is fired when the XUL error page comes up. So I was wrong in the original summary. We receive a STATE_STOP progress listener notification when the XUL error page comes up, but we also receive PageHide right after that, which makes us destroy the current document accessible. Not sure how we should know that the current PageHide should be ignored because there is an error page there.

It seems okay to keep around the accessible cache for a document that's cached. Doing so gets around the problem of the document being destroyed because of the PageHide that occurs when a XUL error page is shown.

Comment on attachment 189380 [details] [diff] [review] 1) Use START_START instead of STATE_TRANSFERRING (which may not be fired if page not found), 2) Only destroy accessible document for "unload" not "PageHide" a=mkaply

Checking in nsAccessibilityService.cpp; /cvsroot/mozilla/accessible/src/base/nsAccessibilityService.cpp,v <-- nsAccessibilityService.cpp new revision: 1.147; previous revision: 1.146 done Checking in nsRootAccessible.cpp; /cvsroot/mozilla/accessible/src/base/nsRootAccessible.cpp,v <-- nsRootAccessible.cpp new revision: 1.125; previous revision: 1.124 done

This patch caused a *massive* leak -- i.e., we basically don't free at least a significant portion of content nodes until shutdown when the system accessibility preference is enabled. (This means we also leak raw image data, which is huge.) See bug 330624.