Forked from https://bugzilla.mozilla.org/show_bug.cgi?id=965912#c31 We need to review what is done in the Nuwa process and move cross-process observers and the like after the content process is forked from Nuwa.

Should we consider to provide a generalize way to notify observers cross process, a cross process observer service, for example, so we can centralize them and handle them at once? Forwarding notifications to content process seems pretty common in our code, and people might add new cross observer after we fix this.

If there is more than just the system time zone observer to worry about, yes, we should think about somehow handling this case.

This is what the Nuwa process sends to the b2g process during startup until NuwaReady: [time:1394018817995051][11366->11286][PContentChild] Sending Msg_PCrashReporterConstructor([TODO]) [time:1394018818005488][11366->11286][PContentChild] Sending Msg_GetProcessAttributes([TODO]) [time:1394018818124537][11366->11286][PContentChild] Sending Msg_ReadPrefsArray([TODO]) [time:1394018818282740][11366->11286][PContentChild] Sending Msg_PNeckoConstructor([TODO]) [time:1394018818389429][11366->11286][PContentChild] Sending Msg_PJavaScriptConstructor([TODO]) * [time:1394018818391932][11366->11286][PContentChild] Sending Msg_AsyncMessage([TODO]) * [time:1394018818460444][11366->11286][PContentChild] Sending Msg_BroadcastVolume([TODO]) [time:1394018818472742][11366->11286][PContentChild] Sending Msg_GetXPCOMProcessAttributes([TODO]) [time:1394018818525294][11366->11286][PContentChild] Sending Msg_NuwaReady([TODO]) The starred ones are noteworthy. Questions are: 1. Msg_AsyncMessage comes from > cpmm.sendAsyncMessage("Activities:GetContentTypes", { }); in b2g/components/ContentHandler.js to get content types. dom/activities/src/ActivitiesService.jsm queries db and sends content types back. The question is: does this need to be done per content process? Are content types in db static during the running of b2g? If not then we have a bug here. 2. In nsVolumeService.cpp:93 we do this: > ContentChild::GetSingleton()->SendBroadcastVolume(NS_LITERAL_STRING("")). Do we need to do this for each content process? If so then we have a bug here.

ni :fabrice for question 1 above.

ni Hsinyi for question 2 above since this is looks like to be relevant to telephony.

Yes, the activity part needs to be done in each content process to register the content handlers. And that can be potentially updated when a new app is installed, which means that this is definitely not static data. :(

(In reply to Cervantes Yu from comment #5) > ni Hsinyi for question 2 above since this is looks like to be relevant to > telephony. Dave would be the better person for the question. ni him :)

(In reply to Cervantes Yu from comment #3) > 2. In nsVolumeService.cpp:93 we do this: > > ContentChild::GetSingleton()->SendBroadcastVolume(NS_LITERAL_STRING("")). Do we need to do this for each content process? If so then we have a bug here. It's needed for each content process which uses the volume service. Basically, the volume service is maintaining a per-child cache so that it can query the state information Basically, if a particular client needs to use device storage, then it will do: http://dxr.mozilla.org/mozilla-central/source/dom/devicestorage/nsDeviceStorage.cpp#729 and expect that the cache is up-to-date. So I guess it depends on when the VolumeService constructor is called. All services which are aware of child/parent stuff will have this issue. Maybe there's a different way to achieve the same thing?

(In reply to Dave Hylands [:dhylands] from comment #8) > (In reply to Cervantes Yu from comment #3) > It's needed for each content process which uses the volume service. > Basically, the volume service is maintaining a per-child cache so that it > can query the state information > > Basically, if a particular client needs to use device storage, then it will > do: Can we make it lazily loaded instead of registering it in "app-startup" category? It doesn't sound like a must for each app.

Nuwa is gone after bug 1284674.