286125 - Fastload assertion on partially invalid fastload files

Status: RESOLVED INVALID

(Core :: XUL, defect)

Description

[Blake Kaplan (:mrbkap) (inactive)]

I've been seeing "URI mapped to two different specs?" occasionally on startup
and finally got around to looking into it. Unfortunately, I managed to nuke the
fastload file that was giving me problems, so I can't reproduce it right now.

The problem appears to be in nsXULDocument::ResumeWalk(). On line 3050, it calls
nsXULPrototypeCache::GetPrototype(), which ends up calling
nsFastLoadService::StartMuxedDocument(). If the entry exists, but is somehow
malformed (in the case I was seeing, deserialization was failing), then we fall
to the case on line 3097. This ends up calling NS_OpenURI, which creates a new
chrome protocol handler, which also calls GetPrototype() on the same URI. This
causes the assertion.

The current plan of attack is to remove the GetPrototype() from ResumeWalk, and
simply handle the caching and loading in the chrome protocol handler.

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

I haven't seen this assertion in a long time and don't know how to reproduce this anymore. Oh well.