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. 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.

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.

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.
  - We should feel free to break existing necko APIs here (and in general) if it makes life easier.

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 suggested yesterday that we could 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.

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.

Channel "owner": What's this frob for? Does setOwner need to propagate across chrome/content?

Carving work into subprojects

FTP is a great sub-project for someone... Volunteers?

Other sub-projects will probably emerge, but I can't think of them just yet--ideas?

Attendee List

Jason Duell
Boris Zbarsky
Johnny Stenback
roc
davidb
joe

Necko: Electrolysis design and subprojects

Contents