This templated prerendereing sounds like a complicated API. Is there any
advantage of this over what is possible today with a single page
application using history.pushState?
Den 12-08-2014 kl. 00:03 skrev Jonas Sicking:
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
