Very exited to see this happening. Implementation issues aside, I have two comments:
* This is something that we really need on FirefoxOS. I hope that the implementation strategy will work there too? * A use-case that we came upon pretty quickly when we were looking at using prerendering in FirefoxOS is that we might not know the exact URL that the user is likely to navigate to, but we have a pretty good guess about what template page it's going to be. Consider for example bugzilla. After the user has done a search query, they are likely to click on one of the bug links. Each bug has a different URL, but all bugs share much of the page UI. It would be really awesome if bugzilla could ask to prerender a URL like "https://bugzilla.mozilla.org/show_bug.cgi?justLoadTemplate=true";. Then when the user clicks a bugzilla URL like "https://bugzilla.mozilla.org/show_bug.cgi?id=123456";, we would enable webpage logic to somehow force the prerendered page to be used, even though the URLs don't match. One way to do this would be to enable some way for the current page to talk to the prerendered page. The current page could then tell the prerendered page "the user just clicked bug 123456", at which point the prerendered page could use replaceState to change its URL to "https://bugzilla.mozilla.org/show_bug.cgi?id=123456";, at which point we would see that the URLs matched. Another solution would be to enable the prerendered page to say "i'm able to act as a prerender page for any URLs that match pattern https://bugzilla.mozilla.org/show_bug.cgi?id=*";. Would be great if someone could bring up this use case with the prerender editors and make sure it gets covered and that a specced solution is defined. / Jonas On Mon, Aug 11, 2014 at 11:47 AM, Roshan Vidyashankar <roshan...@gmail.com> wrote: > Summary: The Prerendering API 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. It's a gecko API that consumers can choose to use. For > now, we're not talking about exposing this to web pages yet, or even using it > in any of our products, we're just working on the implementation. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=730101 > > Link to standard: At some point we are going to be contributing to a spec but > there are a number of unknown things which we're hoping to find out through > the implementation - like what APIs need to be blacklisted in prerendering > (audio, window.open etc). Chrome and IE have shipped their own > implementations of prerendering. > > Platform coverage: All > > Estimated or target release: Unknown > > Preference behind which this will be implemented: dom.prerendering.enabled > > Implementation Plan > There are two big parts to the implementation. > > 1. How do we handle the prerendering itself in a way that works both for > desktop and b2g > > For this, we're thinking about adding a boolean flag to nsDocShell which > together with mIsActive will constitute a tri-state: "active", "inactive" and > "prerendered". As far as the outside code is concerned, prerendered > docshells are treated as inactive ones for the most part. This means that > we'd basically need to not modify nsDocShell::GetIsActive, and audit all of > its callers and find the potential consumers who would want to treat > prerendered and inactive differently (I don't expect there to be any such > consumers actually but we'll see). We'd use the prerendered state to reflect > the correct status reflected through the page visibility API. The > prerendered docshell masquerading as inactive will also mean that it won't > get a rendering on b2g for example because that's how we hide mozbrowser > iframes there. > > In order for gaia and XUL based consumers to be able to control the > prerendering, I think we'd need to use the nsIFrameLoader swapping facilities > that we currently have for the <xul:browser> swapDocShells method and extend > those to make them usable with the mozbrowser frameLoader as well. That way > we can expose the prerendering API through both mozbrowser and <xul:browser> > while sharing hopefully most of the code between these different consumers, > and we'd get the ability to swap the frame loaders when we need to actually > render a prerendered document. > > 2. What do we do with the APIs that have undesirable side-effects in > prerendered pages (audio, window.open etc). > > We first need to decide what we're going to do when a page calls into an API > which has undesired side effects (and that is a blurry line -- I hope as part > of this we come up with an actual list of what those actions are!). Chrome > basically aborts the execution of scripts on the page and throws out the > prerendered content as soon as any such APIs are called. IE's documentation > claims that they "pause" a web page execution when that happens, but > according to my testing, that behavior is really border-line > non-deterministic. I think we basically have two options: either abort the > execution of the script or throw an exception. The former breaks > run-to-completion, which sucks. The latter is a bit better I think but then > we need to detect when JS execution is "done" so that we can start to discard > the prerendered content. I don't know if the latter is easily doable. > > We are also thinking about adding a WebIDL annotation (let's call it > [UnsafeForPrerendering] that we can add to stuff in the IDL and have it call > into a BindingUtils helper which does either of the above. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
