I found this issue when I try to address 96678 (and . We try to speed up the start up loading time by remove unnecessary init code . What I found is the HTTP handler got create in nsScriptSecurityManager::InitPrincipals even we simply run a mozilla -chrome file:/c:/temp/minimal.xul ( see bug 75041 for details) It looks like in the initialization time nsScriptSecurityManager::InitPrincipals read in the perference and iterate through the pref, for each iteration, it will call nsCodebasePrincipal::InitFromPersistent and therefore call NS_NewURI which will eventually create a protocol handler. Is that possible that we can delay such call (nsCodebasePrincipal::InitFromPersistent) untill we hit a related url ? in the test case provide by 75041, we only load file: url and somehow in this place we create a http handler for it.

This call to NS_NewURI has caused problems before - it once caused an infinite recursion on startup, which we fixed through other menas. The reason I use NewURI here is to take advantage of the URL parser - we read a URL string out of prefs and we'd like to store it as an NSIURI, not a string. We could just save it as a string initially and parse it lazily, but this just adds another level of complexity to the caps code, which I'm trying desparately to keep simple to make it easier to keep secure. I'm willing to revisit the idea of doing this lazily, though. Maybe someone can think of an alternative. What's your timeframe on this? Is it targeted for 0.9.4?

performance, footprint, feature work, and re-architecture bugs will be addressed in 0.9.8

Future

Isn't this related to the workaround for bug 89488? Should it go to the OJI folks?

This should have been fixed by the removal of the workaround for bug 89488.

Is this fixed?