Re: E10s architecture

On 10/20/09 8:01 AM, Olli Pettay wrote:
> Hi all,
> 
> since I've just started some e10s work, I don't know if this has been
> discussed or documented somewhere.
> I'm not even sure who to send this email.

mozilla.dev.tech.dom is the group we're using for e10s stuff.

> To get the setup working, some methods of nsIWebBrowser (and related
> interfaces) need to be exposed on chrome side. As a quick hack I just
> added activateRemoteFrame() (basically the same as
> nsIWebBrowserFocus.activate()) to nsIFrameLoader. But that is ugly. The
> method doesn't have much to do with nsIFrameLoader. Same could be
> said about updatePositionAndSize(). The tilebrowser patch adds yet
> another method.
> So what I'm asking is that, is there a plan how to expose content
> browser methods to chrome process?

Not a firm one, no. I thought briefly about whether we should have a "remote
docshell" interface which would unify the local and remote browser APIs, but
I haven't gone through enough of the API to decide what's best. bz may have
thoughts too.

> I think we need a new (scriptable?) interface for content browser,
> maybe IRemoteBrowser. nsIFrameLoader could have a member .remoteBrowser
> which would return null for non-remote cases. IRemoteBrowser could
> hopefully contain all the methods that will be needed to control the
> content browser. Also, the implementation for IRB should probably handle
> TabParent instance. Actually, IBR would in most cases just forward calls
> to TabParent, and vice-versa.

In general, yeah. For listener-type interfaces it would probably keep a
local list and just proxy the data once across the wire and send it to the
list of listeners. And it all has to be async.

Long-term, I'd strongly prefer an interface shared for both local and remote
iframes, but in order to get fennec demos up short-term I don't think that's
necessary or realistic.

> Another thing not clear to me is the destroying of content browsers.
> IBR would certainly have some methods for that, like destroy(), so that
> unload events can be fired in content browser, if the browser is still
> alive. But there are also things like tearing down widget hierarchy. In
> gtk we seem to create a new "socket widget" on chrome side, but never
> remove it. Does the removing happen automatically when content process
> dies or should it be done manually? We certainly need some notification
> in IBR implementation when the content process dies so that UI and
> other things can be cleaned up. I have no idea how to do that? Does our
> IPC provide some signal or notification when a content process dies?

Not yet. There are bugs filed for most of this, see
https://bugzilla.mozilla.org/showdependencytree.cgi?id=electrolysis&hide_resolved=1
and in particular bug 513354. But I wouldn't worry about it right now, since
it doesn't matter for the Fennec stuff yet (we'll just leak, and that's ok!)

> Next thing I need to think about is how chrome can listen for events in
> content. Especially, how to expose event targets in chrome. JPW or
> something similar is perhaps needed. Though, JPW is for JS only, and I
> think we will need something for C++ too.

Right now I'm really hoping we don't have to bubble events across the
process boundary by default. If you want events for a particular frame/tab,
you have to explicitly register an event listener with that window.
Firefox/Fennec UI code would use an async API where any necessary
information about the event is gathered in the content process and forwarded
to the chrome process.

> Or perhaps some of the chrome could run in content process. Something
> which can access content and use the content->chrome API (but not any
> other privileged API). Then event listeners could be pushed down from
> chrome to contentChrome layer. (This would break extensions and current
> FF UI, sure.)

Exactly. We'll still probably need some compat layer for extensions to do
synchronous stuff using JPW, but that should be discouraged. Anyway, I don't
think we need it immediately for Fennec, so we can postpone it a bit.

The things I do need for a useful Fennec demo are:

* nsIWebProgressListener.onStateChange and .onLocationChange. I don't need
the nsIRequest, just the flags/status. I don't know how we want to deal with
the nsIURI aLocation: for now we've just been passing URIs as strings, which
is probably sufficient for now but may be a pain later. This is partly
covered by bug 514705, which is assigned to robin_bb, but I don't think he's
actively working on it.

* MozScrolledAreaChanged and MozAfterPaint event forwarding
(content->chrome), in order for the tilebrowser to work correctly. This
doesn't look hard, so I may be able to do it myself.

--BDS