In bug 1158404, a class in the child process is waiting for profile-change-net-teardown, but we never trigger that in the child. Somebody should look into seeing how much that happens in the child process. If there are few enough places, maybe an assertion could be added somewhere.
nsIOService::IoService(), nsSocketTransportService::Init(), nsStringBundleService::Init(), mozilla::dom::DOMStorageObserver::Init(), mozilla::net::CacheObserver::Init(), mozilla::InitOSFileConstants() (This is trying to retrieve the profile directory, and so it waits for profile change.), nsExternalHelperAppService::Init(), some stuff written in JS, mozilla::net::nsHttpHandler::Init(), nsLayoutStylesheetCache::nsLayoutStylesheetCache() (One kind of style sheet that this caches is associated with the user profile). I stopped at that point. There's probably other stuff.
Created attachment 8675916 [details] [diff] [review] Report things trying to observe profile-related topics in the child process. Not for landing.
There's a ton of this, and I'm not sure it is worth digging through all of the places where it doesn't matter much.
I would think cases should either be fixed or removed. Is there a third category?
For at least a few of the ones I looked at, the error is mostly benign. I'm not sure it is a big improvement to just go through all of these places and check which process we are in before calling AddObserver, without getting to the point where we can declare these verboten entirely. Interestingly, in the block of code right before where my patch does stuff, you can see that it does exactly this for some http-on-* things.
You need to log in before you can comment on or make changes to this bug.