So we're now shipping HTTPS requests to the chrome process. To save memory we want to turn off NSS in the children. This may be as simple as just finding the init code and disabling it if #defined MOZ_IPC && IsNeckoChild() == true. But first we need to know if any other code uses NSS in the child besides HTTPS. Dougt mentioned that some things might use NSS via PSM.

http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/public/ has the PSM interfaces. I didn't see any obvious clients of it in mxr that we need to worry about, but didn't search extensively. We could probably use someone who actually knows the NSS code to help us a little with this. Bueller?

Over to bsmedberg who'll add a fatal assert if NSS is touched, so we can see what's using NSS now that we've removed HTTPS from content. The most likely culprit is the JS crypto code: I've opened bug 561244 for that. Rumor has it that if nothing uses NSS, it doesn't get initialized and hog memory: we should verify that.

This is the most basic thing, which prevents any PSM classes from being initialized.

Adding dep on the channel classifier being run in the chrome process that heavily uses crypto code.

Comment on attachment 445120 [details] [diff] [review] Disable NSS/PSM in the content process, rev. 1 After all bugs blocking this one lands we can give this a try. ATM I don't about anything else using nss.

Security UI on the child process is collecting all information about the security state and forwards that to the TabParent. One of this information is the EV (extended validation) status. The check cannot be done on the child process because it requires the nss be initialized and doesn't work on the child process anyway (needs access to the cert database of the profile). Bug 536301 is going to move this check to the parent process. W/o it we don't have the EV status visible.

This patch should fix the shared build bustage. This affects c-c since we don't --enable-libxul nor do we have xul.lib before this dir's link happens. It is a sorta-hack since MOZ_IPC is not defined unless we are libxul, but since this code is not really useful unless MOZ_IPC is defined anyway, it doesn't hurt anything to ifdef based on it.

Gah. It's not like we like having MOZ_IPC disabled in our builds, but if we must, it would really be nice if it at least builds. Thanks, Justin, for that patch!

Comment on attachment 464204 [details] [diff] [review] Fix for shared build bustage Hoping that honza might be around soon to give this a review so comm-central can go back to green.

Comment on attachment 464204 [details] [diff] [review] Fix for shared build bustage r+a=me; this is breaking my builds.

C(In reply to comment #9) > Comment on attachment 464204 [details] [diff] [review] > Fix for shared build bustage Checked in: http://hg.mozilla.org/mozilla-central/rev/be806599987a