Edit Prerendering: User:SOFTowaha

Prerendering implementation plan for Gecko

Introduction

Prerendering is a yet-to-be-standardized technology first introduced by Chrome and later adopted by IE which allows the rendering engine to start loading and rendering a web page without any visible UI until the page needs to be displayed to the user. The basic mechanics of the technology are as follows:

• The trigger for prerendering a page. The prerendering operation is controlled by the UA, so the UA will ultimately remain in charge to determine whether to prerender a page and also whether to use the prerendered page when it needs to display the page to the user. For example, the UA may decide to prerender pages that it thinks the user has a high chance of visiting without any indication from the web page, or it may not honor the page's request for a link to be prerendered if it determines that the amount of available memory is not enough for that, etc.
• The Web-facing API. Both Chrome and IE have extended the Page Visibility API for prerendering support, by returning "prerender" from document.visibilityState and true from document.hidden if the page is being prerendered, and also by firing a visibilitychange event when the document is first presented to the user.
• Black-listing problematic functionality. This is by far the biggest chunk of work. There are a number of features which have undesired side-effects such as window.open (you don't want an invisible document being rendered to be able to open a new window) and there are other things such as instantiating plugins on those documents which can have either unknown side effects or can take a lot of effort to make them work properly. Chrome aborts prerendering when it hits these issues. IE seemingly "pauses" the prerendered page and resumes the problematic action (in the case of plugins, delay initializing them). I think it's easiest to abort.

Implementation plan

The implementation work is going to require two big chunks of almost independent parts. One would be identifying the APIs that need to be blacklisted as they are currently not standardized at all, and annotate them in the WebIDL layer if at all possible, or document them separately. Later on we will hook up those annotations to the aborting mechanism. The abortion mechanism is basically going to be calling JS_RequestInterruptCallback and making sure that we return false from the interrupt callback to abort the execution of the content script and tearing down the resources etc.

The other part would be to figure out how the prerendering infrastructure would work. We will probably use a docshell set to be invisible. The exact mechanics are probably going to be different in desktop vs. mobile.

We should also make the prerendering functionality available as APIs that clients can use. This could be for example a mozbrowser API for b2g, or an API on <xul:browser> for desktop and fennec. More details to come.