Re: Intent to implement: Prerendering API
Jonas, Le 12 août 2014 à 08:33, Jonas Sicking a écrit : > However in some cases we can do better than that by loading a template > page that can be used for multiple of the search results. This I'm not sure to understand how that would be working. Let's say be any page on the Web. How do you know in advance the template for the page? I might have missed something. For things owned by Mozilla. It would mean that you would send HTML templates fed with JSON data? Do you do partial rendering in this case? How does it work with injected data modifying the HTML template layout? > Also note that this isn't just useful for search results. I was not thinking about search results most of the time. Search results or any sequential web thingy (manual, gallery, etc. etc.) is just an obvious one. > Where it came up for FirefoxOS is in the contacts list, where it's likely that > the user is going to press one of the contacts, but guessing which one > is unlikely to be successful. hmmm… back button is about "caching the past". Easy to pre-render. links and prefetch is about "caching the future". Harder to pre-render. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
On Mon, Aug 11, 2014 at 3:40 PM, Karl Dubost wrote: > > Le 12 août 2014 à 07:03, Jonas Sicking a écrit : >> * 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. > > If I remember bits of Google strategy, it was basically tied to their proxy > servers where they basically know statically which page the users are most > likely to click next. In the Google search page use case (if that's the case you are talking about?) the resulting pages generally don't share a "template". This means that they have to make a best guess at which page to load, and if they guess wrong the prerendering was for naught. However in some cases we can do better than that by loading a template page that can be used for multiple of the search results. And even better, we can do it at a dramatically lower cost since we don't have to worry about implementing the AI for guessing which result the user is going to click. Also note that this isn't just useful for search results. Where it came up for FirefoxOS is in the contacts list, where it's likely that the user is going to press one of the contacts, but guessing which one is unlikely to be successful. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
an obvious tie in here is the network predictor (formerly 'seer') work Nick Hurley has been doing. Basically already working on the "what to fetch next" questions, but not the rendering parts. On Mon, Aug 11, 2014 at 6:40 PM, Karl Dubost wrote: > > Le 12 août 2014 à 07:03, Jonas Sicking a écrit : > > * 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. > > If I remember bits of Google strategy, it was basically tied to their > proxy servers where they basically know statically which page the users are > most likely to click next. > > There are also some logical next steps: > > * Infinite loading through XHR > * Next items in a list of search results, gallery, etc. Anything > sequential. (Next, Prev) > > A bit more far fetched but maybe worth thinking for a version 2.0 > heuristics. If it's only client-side, users could set up their browser to > collect the browsing habits for the most common sites (*without ever > sending it back to a server*). With this browsing habits sequence, it would > be possible to know for the browser that most of the time the user follows > a certain pattern and pretender the pages. Additional possible benefits: > User understands his/her own patterns through a dashboard. > > -- > Karl Dubost, Mozilla > http://www.la-grange.net/karl/moz > > ___ > 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
Re: Intent to implement: Prerendering API
Le 12 août 2014 à 07:03, Jonas Sicking a écrit : > * 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. If I remember bits of Google strategy, it was basically tied to their proxy servers where they basically know statically which page the users are most likely to click next. There are also some logical next steps: * Infinite loading through XHR * Next items in a list of search results, gallery, etc. Anything sequential. (Next, Prev) A bit more far fetched but maybe worth thinking for a version 2.0 heuristics. If it's only client-side, users could set up their browser to collect the browsing habits for the most common sites (*without ever sending it back to a server*). With this browsing habits sequence, it would be possible to know for the browser that most of the time the user follows a certain pattern and pretender the pages. Additional possible benefits: User understands his/her own patterns through a dashboard. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
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 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 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 > 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 th
Re: We should drop MathML
On Sunday, May 5, 2013 10:27:41 PM UTC-7, p.kraut...@gmail.com wrote: > 2.1 you claim MathML never saw traction outside of Firefox. I tried to point > out that MathML has huge traction in publishing and the educational sector, > even if it wasn't visible on the web until MathJax came along. Google wants > MathML support (they just don't trust the current code) while Apple has > happily advertised with the MathML they got for free. Microsoft indeed > remains a mystery. Actually, MS is very clear on their position on MathML in Internet Explorer: http://status.modern.ie/mathml?term=mathML ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: Prerendering API
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 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 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
