E10s: "content driver"

Hi all,

I've been thinking about the content-to-chrome event handling,
and serializing and de-serializing event would be otherwise
pretty easy, but handling event targets is tricky.
(I'm going to implement serialization for MozAfterPaint etc so that we 
can prototype some Fennec-like implementation.)

So I've tried to come up with something where event target handling
would happen mainly in content process.
The idea is to hook content process WindowRoot's event handling related
methods to a new JS context. That context should have access to content
DOM and to an API to send messages to chrome process, but no chrome
privileges.

When content process is initialized, chrome would activate
event listeners in this new layer (I've used "content chrome" name
  before, but perhaps "content driver" is better.)
Also extensions could send new event listeners to the content driver.
Event listeners could then communicate with chrome using "remote
chrome" API, which would probably look a bit like
nsIWebBrowserChrome/nsIEmbeddingSiteWindow/nsIWebBrowserChromeFocus
/nsIContextMenuListener/nsITooltipListener/nsIWebProgressListener.
The API should also have some generic way to send and receive JSON
data.

I *think* without some kind of content driver layer we'll end up having
something pretty close to 
http://mxr.mozilla.org/seamonkey/source/ipc/ipcd/, especially dconnect.

But, content driver makes it harder to develop extensions and FF
UI. Developer needs to split code to be executed in chrome and in
content driver.

Comments?


-Olli