Comment 50 for bug 274065

(In reply to comment #47)
> (In reply to comment #37)
> > Now I can tie the NSS assertion, FoxyProxy, and the XMLHttpRequest change
> > together. In 2.0.0.17 w/FoxyProxy the first call to the nsNSSComponent
> > constructor is due to FoxyProxy doing a XMLHttpRequest to load
> > "chrome://foxyproxy/content/strings.xml" during its AppStartup notification.
> > Along the way this calls nsJARChannel::GetOwner(), and that has to check to see
> > if the jar is signed which fires up nsNSSComponent. Apparently it's too early
> > to initialize NSS? nsNSSComponent::Init() fails because it can't get
> > NS_APP_USER_PROFILE_50_DIR. This results in nsNSSComponent service not getting
> > added to the component manager's service hashtable, which means it'll try again
> > later even though nsNSSComponent has now been created and partially
> > initialized.
>
> Yeah as a general rule of thumb you should ignore really doing anything in the
> app-startup notification. The profile has not been selected at that point and I
> think it isn't even determined that the app will not be restarted to
> install/uninstall extensions as well.
>
> The normal pattern is to use an app-startup observer to register for the
> profile-after-change notification in the observer service. This notification
> fires after essentially everything is available. In Firefox 3.1 you will even
> be able to directly register for profile-after-change in the category manager
> and avoid app-startup entirely.

The only thing FoxyProxy does in app-startup is:

gObsSvc.addObserver(this, "quit-application", false);
gObsSvc.addObserver(this, "domwindowclosed", false);
gObsSvc.addObserver(this, "profile-after-change", false);

The XHR to load chrome://foxyproxy/content/strings.xml is done in profile-after-change.