[webkit-dev] Page Visibility API
Hi All, We would like to implement a Page Visibility API in webkit. The corresponding bug is at: https://bugs.webkit.org/show_bug.cgi?id=54181 . The bug has details of the proposal, link to the whatwg discussion as well as a patch. The proposal is also pasted below for convenience. Please let me know if you have any questions / concerns. Thanks Shishir Proposal details Hi all, There is currently no good way for a web page to detect that it is completely invisible to the user (for example, that it is a background tab), although some imperfect heuristics do exist. In the future, there may be cases where such detection is even more important, for example in the prerendering feature that Chromium is currently in the early stages of experimentation with. Note that an earlier version of this proposal was sent to the what-wg mailing list for comment earlier (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029382.html), and received comments that led to several revisions. The following proposal introduces only a minor change on top of the result of that discussion (specifically, renaming document.visibility to document.visibilityState and document.isVisible to document.visible, in order to encourage developers to prefer using the simpler boolean property). Use cases * A page wants to detect when it is being prerendered so it can behave appropriately. * A puzzle game has a timer that keeps track of how long the user has taken to solve the puzzle. It wants to pause the timer when the user has hidden the tab. * A web app that uses polling to fetch dynamic content can pause polling when it knows the page is hidden from the user. * A streaming video site doesn’t want to start the video until the user actually views the tab for the first time (i.e. video shouldn’t start automatically if a user opens the tab in the background). * An in-browser collaborative editing environment wants to update a user’s status to away when the editing surface is not visible to the user. With these use-cases in mind, there are a number of requirements. Requirements * Easy for developers to write scripts that fall back on old behaviors for browsers that do not implement this API * Ability to query the document’s current visibility state * Events fired when the document transitions between visibility states * Ability for browser vendors to add new visibility states in the future Proposed API document.visible Returns true if document.visibilityState’s current value is in the set of visibility states considered to be visible (see the next section for information on document.visibilityState). In practice document.visible is merely a convenience property that is well-suited to simple uses. In most implementations, only the “visible” state is considered visible--although some implementations may consider other values to be visible as well (for example, an implementation that makes use of nearly-full-size thumbnail previews may consider “preview” to be a visible state). document.visibilityState A read-only property that returns a string, one of the values described in the next section. Developers can use the existence of this property to know that they can rely on the rest of this API, too. * Values returned by all conforming implementations * “visible” : the full-size page content may be at least partially visible on at least one screen. * “hidden” : the full-size page content is not visible to the user at all. * Additional values potentially returned by some implementations in some cases * “prerender” : the page is currently being loaded off-screen and might never be shown to the user. * “cache” : the page is currently “frozen” in a cache and not displayed on screen (e.g. the back-forward cache). * “preview” : the page is currently visible only in a lower-resolution thumbnail. States in the second set are not guaranteed to be returned in all cases where they might otherwise appear to apply--it is left to the discretion of the implementation. Additional return values may be added to this API in the future. It is up to the implementation to interpret what these values mean in the precise context of interface and platform. As an example, a current-generation desktop browser might interpret the values the following way: “visible” : the tab is focused in its non-minimized window (regardless of the focus state of the containing window). “hidden” : the tab is backgrounded within its window, or the containing window is minimized. visibilitychange A simple event, fired at the document object immediately after document.visibilityState transitions between visibility states. The event has a property, fromState, that is set to the value of document.visibilityState just before it was changed to the current value. Note that visibility has nothing to do with whether the document’s contents have fully loaded or not, which implies that for any given visibility transition event, onload may
Re: [webkit-dev] Page Visibility API
requestAnimationFrame may provide a method for 'pausing', when following a window blur event. It was recently added. -Charles On Mar 8, 2011, at 11:35 AM, Shishir Agrawal shis...@chromium.org wrote: Hi All, We would like to implement a Page Visibility API in webkit. The corresponding bug is at: https://bugs.webkit.org/show_bug.cgi?id=54181 . The bug has details of the proposal, link to the whatwg discussion as well as a patch. The proposal is also pasted below for convenience. Please let me know if you have any questions / concerns. Thanks Shishir Proposal details Hi all, There is currently no good way for a web page to detect that it is completely invisible to the user (for example, that it is a background tab), although some imperfect heuristics do exist. In the future, there may be cases where such detection is even more important, for example in the prerendering feature that Chromium is currently in the early stages of experimentation with. Note that an earlier version of this proposal was sent to the what-wg mailing list for comment earlier ( http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029382.html), and received comments that led to several revisions. The following proposal introduces only a minor change on top of the result of that discussion (specifically, renaming document.visibility to document.visibilityState and document.isVisible to document.visible, in order to encourage developers to prefer using the simpler boolean property). Use cases * A page wants to detect when it is being prerendered so it can behave appropriately. * A puzzle game has a timer that keeps track of how long the user has taken to solve the puzzle. It wants to pause the timer when the user has hidden the tab. * A web app that uses polling to fetch dynamic content can pause polling when it knows the page is hidden from the user. * A streaming video site doesn’t want to start the video until the user actually views the tab for the first time (i.e. video shouldn’t start automatically if a user opens the tab in the background). * An in-browser collaborative editing environment wants to update a user’s status to away when the editing surface is not visible to the user. With these use-cases in mind, there are a number of requirements. Requirements * Easy for developers to write scripts that fall back on old behaviors for browsers that do not implement this API * Ability to query the document’s current visibility state * Events fired when the document transitions between visibility states * Ability for browser vendors to add new visibility states in the future Proposed API document.visible Returns true if document.visibilityState’s current value is in the set of visibility states considered to be visible (see the next section for information on document.visibilityState). In practice document.visible is merely a convenience property that is well-suited to simple uses. In most implementations, only the “visible” state is considered visible--although some implementations may consider other values to be visible as well (for example, an implementation that makes use of nearly-full-size thumbnail previews may consider “preview” to be a visible state). document.visibilityState A read-only property that returns a string, one of the values described in the next section. Developers can use the existence of this property to know that they can rely on the rest of this API, too. * Values returned by all conforming implementations * “visible” : the full-size page content may be at least partially visible on at least one screen. * “hidden” : the full-size page content is not visible to the user at all. * Additional values potentially returned by some implementations in some cases * “prerender” : the page is currently being loaded off-screen and might never be shown to the user. * “cache” : the page is currently “frozen” in a cache and not displayed on screen (e.g. the back-forward cache). * “preview” : the page is currently visible only in a lower-resolution thumbnail. States in the second set are not guaranteed to be returned in all cases where they might otherwise appear to apply--it is left to the discretion of the implementation. Additional return values may be added to this API in the future. It is up to the implementation to interpret what these values mean in the precise context of interface and platform. As an example, a current-generation desktop browser might interpret the values the following way: “visible” : the tab is focused in its non-minimized window (regardless of the focus state of the containing window). “hidden” : the tab is backgrounded within its window, or the containing window is minimized. visibilitychange A simple event, fired at the document object immediately after document.visibilityState transitions between visibility
[webkit-dev] device consensus?
Hi Adam and Leandro, There was as long thread on webkit-dev a few weeks ago entitled Implementing the device element. Did you two reach some sort of consensus on that thread? Would one or both of you be willing to summarize your conclusions so I don't have to wade through the whole thing? Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XHTMLMP support
Currently, XHTMLMP is used in webkit browser for mobile business. So, I think it's good to leave it for a while :) 2011. 3. 8., 오전 5:09, Eric Seidel 작성: Are any ports still using that? Or should we remove it. If so, happy to leave it in. But if no ports are actively using it, its best to remove the code (and restore it from SVN history later if someone needs it again). -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XHTMLMP support
Which WebKit browser is using XHTMLMP? - James On Tue, Mar 8, 2011 at 4:43 PM, Ra Kyounga kyounga...@gmail.com wrote: Currently, XHTMLMP is used in webkit browser for mobile business. So, I think it's good to leave it for a while :) 2011. 3. 8., 오전 5:09, Eric Seidel 작성: Are any ports still using that? Or should we remove it. If so, happy to leave it in. But if no ports are actively using it, its best to remove the code (and restore it from SVN history later if someone needs it again). -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XHTMLMP support
I'm not sure any product using it is released officially. but, I think mobile industry want it. currently. Or, how about HTC freestyle? 2011. 3. 9., 오전 9:46, James Robinson 작성: Which WebKit browser is using XHTMLMP? - James On Tue, Mar 8, 2011 at 4:43 PM, Ra Kyounga kyounga...@gmail.com wrote: Currently, XHTMLMP is used in webkit browser for mobile business. So, I think it's good to leave it for a while :) 2011. 3. 8., 오전 5:09, Eric Seidel 작성: Are any ports still using that? Or should we remove it. If so, happy to leave it in. But if no ports are actively using it, its best to remove the code (and restore it from SVN history later if someone needs it again). -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XHTMLMP support
So you're suggesting that BREW is the only WebKit port to use XHTMLMP? http://www.htc.com/us/support/freestyle-att/tech-specs/ suggests the HTC freestyle uses BREW. As far as I can tell, the Gtk and Qt builds have support for building with XHTMLMP (no other build does), but neither of them have it enabled by default. Again, I'm certainly not against it. Just looked like it was not in use (and possibly broken) so am asking who is using it. Seems the current answer is no one, except maybe a secret port? -eric On Tue, Mar 8, 2011 at 10:59 PM, Ra Kyounga kyounga...@gmail.com wrote: I'm not sure any product using it is released officially. but, I think mobile industry want it. currently. Or, how about HTC freestyle? 2011. 3. 9., 오전 9:46, James Robinson 작성: Which WebKit browser is using XHTMLMP? - James On Tue, Mar 8, 2011 at 4:43 PM, Ra Kyounga kyounga...@gmail.com wrote: Currently, XHTMLMP is used in webkit browser for mobile business. So, I think it's good to leave it for a while :) 2011. 3. 8., 오전 5:09, Eric Seidel 작성: Are any ports still using that? Or should we remove it. If so, happy to leave it in. But if no ports are actively using it, its best to remove the code (and restore it from SVN history later if someone needs it again). -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit2 GTK port MiniBrowser
Hi All, Has anybody written GTK version of MiniBrowser or any sample application using WebKit2? It will be a great help if you can share some information about how to develop WebKit2 GTK applicaton. Thanks Regards, ROSE-nd-ASH ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit2 GTK port MiniBrowser
On Wed, 2011-03-09 at 11:47 +0530, ROSE-nd-ASH wrote: Hi All, Has anybody written GTK version of MiniBrowser or any sample application using WebKit2? It will be a great help if you can share some information about how to develop WebKit2 GTK applicaton. Looks like development is still in priogress.. Please check this: [GTK] WebKit2 MiniBrowser metabug https://bugs.webkit.org/show_bug.cgi?id=52805 Regards Lukasz Slachciak ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
