Open
Bug 1217573
Opened 9 years ago
Updated 2 years ago
Audit the consumers of Necko to look for Necko APIs used in the child process that aren't available there
Categories
(Core :: General, defect, P4)
Core
General
Tracking
()
NEW
Tracking | Status | |
---|---|---|
e10s | + | --- |
People
(Reporter: ehsan.akhgari, Unassigned)
References
Details
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 2•9 years ago
|
||
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?
Flags: needinfo?(jduell.mcbugs) → needinfo?(ehsan)
Reporter | ||
Comment 3•9 years ago
|
||
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.
Flags: needinfo?(ehsan)
Updated•9 years ago
|
Assignee: nobody → jduell.mcbugs
Comment 4•9 years ago
|
||
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?
Flags: needinfo?(jduell.mcbugs)
Comment 5•9 years ago
|
||
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).
Flags: needinfo?(jduell.mcbugs) → needinfo?(honzab.moz)
Comment 6•9 years ago
|
||
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.
Flags: needinfo?(honzab.moz)
Comment 7•9 years ago
|
||
We also don't support nsICookieManager (we do support nsICookieService).
Comment 8•9 years ago
|
||
(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•9 years ago
|
||
This was m8 so we'd take a look at it, which I think we have at this point. renom'ing
Updated•9 years ago
|
Updated•9 years ago
|
Priority: -- → P4
Updated•6 years ago
|
Assignee: jduell.mcbugs → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•