Investigate how many observers are added in the child process for shutdown events that will not happen




3 years ago
3 years ago


(Reporter: mccr8, Unassigned)



Firefox Tracking Flags

(firefox44 affected)



(1 attachment)



3 years ago
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.

Comment 1

3 years ago
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.

Comment 2

3 years ago
Created attachment 8675916 [details] [diff] [review]
Report things trying to observe profile-related topics in the child process. Not for landing.

Comment 3

3 years ago
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?

Comment 5

3 years ago
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.