1217573 - Audit the consumers of Necko to look for Necko APIs used in the child process that aren't available there

Status: NEW

(Core :: General, defect, P4)

Description

[(no longer active)]

We need to create a list of Necko APIs that don't work in the child process and audit the code for the usages of those APIs in the child process that may be failing silently without anyone knowing.

Bug 1217571 is one example of what can go wrong here with nsICachingChannel.

Comment 1

[Brad Lassey [:blassey] (use needinfo?)]

Jason, do you want to do this audit?

Comment 2

[Jason Duell]

So our previous approach here has been to call NECKO_MAYBE_ABORT() when an API we don't support on the child is called.  But that's only for IDLs that we partially support (some functions are OK to call, some aren't--those we abort on in debug builds).

We don't currently have anything like this for entire IDLs that are missing in the child.  Perhaps we should hack QI and abort if the child is asked for nsICachingChannel (or any other IDL that parent channels implement but child ones don't).  Ehsan, what do you think of that idea?

Comment 3

[(no longer active)]

Aborting in QI if we ask for a non-existing interface sounds like a fantastic idea!

But note that you won't be able to land that patch because of bug 1217571.  But it'd be nice to hack around that and also deal with other non-existing interfaces and see what this finds.

Comment 4

[Nathan Froyd [:froydnj]]

Jason, I think I have patches that pass try for nsICachingChannel; are there other examples of APIs that should be shut out in the child process?

Comment 5

[Jason Duell]

Honza, can you think of other IDLs we'd want to check here? I'm guessing that across platform there would be quite a few.  NSS-related stuff, socket transport, etc?  (though the socket transport thread continues to linger on the child right now for httpd.js support).

Comment 6

[Honza Bambas (:mayhemer)]

Hmm.. as I understand, you want to simply block ANY class that QI to nsICachingChannel (and any other we may list here) to throw?

I think of following ifaces to black-list as well: 

nsINetworkLinkService, nsIPackagedApp* (probably just *Service, but not sure), nsICacheEntry*, nsICacheStorage*, nsIHttpAuth*, nsISSLSocketControl, nsISOCKSSocketInfo.

According NSS, I lost track some time ago.  :keeler is the one to ask these days.  In my times (looong ago) there were few missing interfaces implementations that I have fixed.

Comment 7

[Jason Duell]

We also don't support nsICookieManager (we do support nsICookieService).

Comment 8

[Honza Bambas (:mayhemer)]

(In reply to Jason Duell [:jduell] (needinfo? me) from comment #7)
> We also don't support nsICookieManager (we do support nsICookieService).

I think there is IPC already under the hood.  I've seen this, but it seems (at the first sight) non-problematic to me.

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

This was m8 so we'd take a look at it, which I think we have at this point. renom'ing