View source for Necko: Electrolysis design and subprojects

This is a page dedicated to the design issues involved in making necko work under electrolysis (i.e. moving all network traffic to the chrome process, and using IPDL to communicate with the content process(es)). 

= Protocols that need work for e10s =

Initially only HTTP/HTTPS/FTP will go over IPC, as the content process must not be allowed to open TCP/IP or other network connections. 

FTP may be fudged (see section below) so that we don't require using IPC for it.  

Eventually we plan to sandbox file access, and thus other protocols (about://, file://, jar://) will need some work.  But this is for "Stage 2".

= Implementation design =

Most of necko's logic is going to happen in the chrome process.  

* The content process will create URIs and open Channels, but these channels will essentially be stubs that are connected to a real Channel in the chrome process via IPDL. 

* When an HTTP request is made, for instance, all the nitty-gritty of socket creation, authentication, SSL, cookies, and caching will be made in the chrome process

* The content process will then be notified with the usual OnStartRequest, OnDataAvailable, and OnStopRequest notifications.  

So, the most obvious place for inter-process communication will be AsyncOpen (from content->chrome, to queue the network request) and the various "On..." events back from chrome to the content process.  

The unknown question is how much additional IPDL communication will be needed for the common case.  OnDataAvailable(), etc., all provide pointers to the Channel servicing the request, which allow client code to potentially do things that require access to the chrome channel.  

== General design/architecture issues ==

==== stub classes ====
It's not clear yet when our content "stubs" will be separate classes, or when we'll just add hooks to the existing classes.  Will depend on the class.  nsHttpChannel will have a separate nsHttpChannelChild class, for instance, but nsIOService may just have if(childProcess) checks.

==== Validating data ====
Lucas suggested that IPDL parent actors should take measures to validate data passed to them by children, in case the latter have been compromised (ex: validating that strings are actually UTF-16). In necko's case, that should mainly be the URI and other data for the initial request, but keep in mind for other IPC exchanges, too.

== HTTP and general necko issues ==

==== HTTP Headers ====
HTTP headers will need to be parsed first in the chrome process--so things like auth, cache directives, cookies, etc., can be handled.  We will also need to provide some or all headers to the content process, probably via serializing them over IPDL.  
* bz suggests we "whitelist" the headers and provide only needed headers to the content process.
* we may need to ship the request headers as well as the reply headers to the content process, in order for nsIHttpChannel::getRequestHeader() to work
** Will content process need, or are all uses in chrome? Currently only called by 
*** nsDocument to get Http Referer (this is probably in content?)
*** nsXMLRequest to get Content-Type (to see if preflight request needed)
*** nsFeedSniffer to see if X-Moz-Is-Feed is set 
*** nsIncrementalDownload to keep range header when redirect occurs (chrome?)
*** nsViewsourceChannel to forward getRequestHeader to underlying nsHttpChannel
*** Possible that plugins like Flash call during redirects or at other times?

==== HTTP redirects  ====

The current architecture shifts out the original channel and replaces it with a channel to the new destination. 

*This will probably require IPDL traffic to tell the content process to do something similar on its end. 
*There are also listeners that are notified of redirects, and have the ability to cancel if they don't approve (plugins such as flash use this). 
**There will be listeners that need to notified in both chrome and content processes, so use IPC. 
**But right now these notifications are synchronous: we should change this to async on mozilla-central, and then merge into e10s tree, before trying to implement with IPC. 
***Opened as [https://bugzilla.mozilla.org/show_bug.cgi?id=513086 bug 513086]
*Security concerns
**Is it possible an observer not only cancel a navigation but rewrite/redirect it?  If so how would that change be propagated?
**Is the navigation blocked until all observers return?  Otherwise we might run the risk of a race condition.

==== HTTPS ====
e10s will hopefully not need any mods for HTTPS. 
* One issue: to determine if Lock Icon needed, content process will need handle to securityInfo, which is currently pointed to by nsHttpChannel.  Shouldn't need to actually read security info--see what exactly is needed.

==== LoadGroups ====
LoadGroups will live in the content process.  
* They need to be able to cancel Channels, which should be fairly trivial IPC.  
* When Channels are added to a LoadGroup notifications must be sent, both to DocShell (in content) and various listeners in chrome.  Right now these notifications are SYNC, but we might want to change them to asynchronous to make them play better in the e10s model.  But for now bz/bsmedberg suggest we wait.
* We will need to keep track (via LoadGroups or otherwise) of which channels are "owned" by which content processes, so if one dies, we know to cancel it's requests.

==== Application cache ====
The application cache is fairly recent & is used for offline mode for web apps like gmail.  Unlike the regular HTTP cache, which will be invisible effectively to the content process, the app cache will be visible to the content process, which needs among other things to parse HTTP headers to see if data needs to be cached.
* Presumably cache lives in chrome, and content processes read from it?  Not sure.
* This isn't getting lots of use yet, so it doesn't need to work immediately.
* Honza Bambas and/or Doug Camp (ex-Mozilla) are the ones to ask about this code.

==== EventSink listeners ====
(Firebug, for instance). We'll need to propagate these events to both chrome/content processes, as listeners will live on both.
* ideally we send one IPC msg per event, not one per remote listener.
* don't need much data (HTTP/Channel status?); might need to send the data along in the IPC msg.
* These calls are already async, so no API change should be needed.

==== Suspending channels ====
We suspend Channels from the Download manager, and also when plugins don't consume arriving Channel data quickly enough.  Also HTTP auth?
* We will need to keep around whatever data has arrived but hasn't been delivered, so resume works correctly.  Could happen on either chrome/content end.

==== Http Auth dialog ====
How will chrome know which window to pop Auth tab up in when HTTP auth is needed?  Right now the Channel has callbacks which can be used to get originating window.  We'll need to make this work with e10s, possibly by including window info in chrome Channel when we create it during AsyncOpen.

==== File form POSTs ====
bz suggests that we can accomplish this without having the content process read the file by creating a new kind of stream class, in which the content process marks the name of the file and the chrome process actually reads it from disk and uploads it.

==== Channel "owner" ====
Channels have Set/GetOwner methods, used to store the principal responsible for the request.  
* Apparently not used much for HTTP?
** jst: CSP (Content Security Protocol) may use?
* Not clear if get & set only on content side, or if set only on content, but read by both chrome/content.  Find out and propagate as needed
* bz would like to rework this API anyway

== FTP ==
* Doug Turner knows this code.
* Proposal from bsmedberg:  we keep FTP purely within the chrome process, so that we don't need to make it IPC-savvy.
** We would only allow files to be downloaded (not rendered within browser) via FTP.
** browsing of FTP server tree would be done by hiding content process tab with a chrome one when a FTP directory is the target.
** FTP also supports upload--used by seamonkey and composer--but this happens all in chrome, so no changes needed?

= Carving work into subprojects =

* FTP

* Making redirect notification asynchronous (check in on mozilla-central, then merge to e10s)

* Get simple HTTP networking going, and test just with xpcshell-style tests
** will probably need to rewrite code as we discover issues, so just go for it.

* Figure out which other necko APIs need to be made async, or otherwise changed, or eliminated
** We don't care much about compatibility

= Attendee List =

* Jason Duell
* Boris Zbarsky
* Johnny Stenback
* roc
* davidb
* joe