In order to prototype a new navigation model for Gaia application, where each panel is a single web page, there is a need for a basic prerendering support. The attached patch add such a basic support. It supports a <link rel="prerender" href="foo.html"> tag in the head section of a document, and render the target page into a dedicated docShell. During navigation the content viewer of the dedicated docShell is injected as a child of the original docShell. Everything happens on the main thread, which is a very different approach than Chrome, where a dedicated rendering process is used for such tasks. For B2G/Gaia and the related use cases where the target page is a page of the same application, it seems unclear that it should runs on multiple processes. The side effect is that it introduce much more risk to affect the user experience of the page that is not prerendered, and it should be use with caution. It also only works on e10s enabled build, as it rely on the fact that the parent widget of a content viewer is a PuppetWidget, which makes it easier to reparent it. It is also unclear that it is the correct way to implement prerendering as it may introduce various bugs as injecting a contentViewer of a that comes from an other docShell also need the innerWindow of the prerendering target needs to be reparent to the outerWindow of the original docShell. The wip also bypass all the blacklisting work that has been done in the last year for prerendering. At least this patch let me prototype the navigation model I'm looking for :)

This is not the right approach and is not suitable for landing on mozilla-central.

To expand on this, bug 730101 and its dependencies have implemented some of the ground work, and I have ideas on how to move forward with it. Let's discuss this tomorrow, Vivien!