This would be my inclination as well. I'm not entirely convinced that "every web app should define their own idle timeout" is such desirable behavior that we should build our API around it by forcing every caller to specify their idle timeout - having a standard event that's fired with an exposed state for apps that need it seems like a cleaner approach.<div>
<br></div><div>-atw<br><br><div class="gmail_quote">On Mon, Aug 31, 2009 at 5:03 PM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com">michaeln@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This would be a nice addition... seems like an event plus a read-only property on the 'window' object could work.<div><br></div><div>window.idleState;</div><div>window.onidlestatechange = function(e) {...}</div><div>
<div></div><div class="h5"><div>
<br></div><div><br></div><div><div class="gmail_quote">On Fri, Aug 28, 2009 at 3:40 PM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div></div><div>On Fri, Aug 28, 2009 at 2:47 PM, David Bennett<<a href="mailto:ddt@google.com" target="_blank">ddt@google.com</a>> wrote:<br>
> SUMMARY<br>
><br>
> There currently is no way to detect the system idle state in the browser.<br>
> This makes it difficult to deal with any sort of chat room or instant<br>
> messaging client inside the browser since the idle will always be incorrect.<br>
><br>
> USE CASE<br>
><br>
> Any instant messaging client, or any client that requires user presence,<br>
> will use this to keep track of the users idle state.  Currently the idle<br>
> state of a user inside a browser tell tend to be incorrect, and this leads<br>
> to problems with people being unable to rely on the available status of a<br>
> user.  Without this information it is difficult to do a full featured and<br>
> reliable instant messaging client inside the browser since this makes the<br>
> users' status somewhat unreliable.<br>
><br>
> Lots of social networking sites and other sites centered around user<br>
> interactions on the net keep track of the users idle state for enabling<br>
> interactions with people that are currently online, this would be especially<br>
> useful for interactive online gaming.<br>
><br>
> A process that would like to do some heavy duty processing, like seti@home,<br>
> could use the system idle detection to enable the processing only when the<br>
> user is idle and enable it to not interfere with or degrade their normal<br>
> browsing experience.<br>
><br>
> WORK AROUNDS<br>
><br>
> The idle state of the user is currently detected by looking at the brower<br>
> window and detecting the last activity time for the window.  This is<br>
> inaccurate since if the user is not looking at the page the state will be<br>
> incorrect and means that the idle time is set to longer than would be<br>
> desirable so there is also a window in which the user is actually idle but<br>
> it has not yet been detected.<br>
><br>
> PROPOSAL<br>
> I propose an api which takes in a timeout for idle, the user agent calls the<br>
> callback when the state changes.  Active->idle, Active->away, idle->away,<br>
> idle->active, away->active.<br>
><br>
> The idle times are all specified in seconds, the handler will be called when<br>
> the idle state changes with two arguments and then any user specified<br>
> arguments.  The two arguments are the idle state and the idle time, the idle<br>
> time should be the length of time the system is currently idle for and the<br>
> state should be one of idle, active or locked (screen saver).  The handler<br>
> can be specified as a handler or as a string.<br>
><br>
> Not explicitly specified, and thus intentionally left to the UA, include:<br>
> * The minimum time the system must be idle before the UA will report it [1]<br>
> * Any jitter intentionally added to the idle times reported [1]<br>
> * The granularity of the times reported (e.g. a UA may round them to<br>
> multiples of 15 seconds)<br>
> [NoInterfaceObject, ImplementedOn=Window] interface WindowTimers {<br>
> // timers<br>
> long setSystemIdleCallback(in TimeoutHandler handler, in long<br>
> idleTimeoutSec);<br>
> long setSystemIdleCallback(in TimeoutHandler handler, in<br>
> long idleTimeoutSec, arguments...);<br>
> long setSystemIdleCallback(in DOMString code, in long idleTimeoutSec);<br>
> long setSystemIdleCallback(in DOMString code, in long idleTimeoutSec, in<br>
> DOMString language);<br>
> void clearSystemIdleCallback(in long handle);<br>
> // Returns the current system idle state.<br>
> int systemIdleState();<br>
><br>
> [Callback=FunctionOnly, NoInterfaceObject]<br>
> interface TimeoutHandler {<br>
> void handleEvent(idleState, idleTime, [Variadic] in any args);<br>
> };<br>
><br>
> Where idleState is one of:<br>
>   idleState : active = 1, idle = 2, away = 3<br>
><br>
> Away is defined as locked/screen saver enabled or any other system mechanism<br>
> that is defined as away.<br>
><br>
> This is based on the setTimeout api at <a href="http://www.w3.org/TR/html5/no.html" target="_blank">http://www.w3.org/TR/html5/no.html</a><br>
><br>
> ALTERNATIVES<br>
><br>
> This could be made simple an event listener, where the browser itself keeps<br>
> track of the length of time that is considered idle and fires an event when<br>
> the state changes.<br>
><br>
> setSystemIdleCallback(in IdleHandler handler)<br>
> The downside to this is that it would mean all components on the browser<br>
> would share the same idle time, which would reduce the ability of components<br>
> to choose the most efficent idle time for their use case.  Some IM clients<br>
> might require the user to be there within a very short of period of time to<br>
> increase the likelyhood of finding a person.  It would also not let the<br>
> components let the user choose their idle time.<br>
><br>
> The upside to this proposal is it would be a lot simpler.<br>
><br>
> REFERENCES<br>
><br>
> 1] There is research showing that it is possible to detemine a users key<br>
> strokes and which keys they are actually typeing by using millisecond<br>
> accuracy idle time information.  This is the reason this spec emphasises the<br>
> jitter and granularity aspects of the idle detection.<br>
> <a href="http://portal.acm.org/citation.cfm?id=1267637" target="_blank">http://portal.acm.org/citation.cfm?id=1267637</a><br>
><br>
> Questions, Comments, etc.<br>
><br>
> What do others think of this addition? Does anyone have an idea for a better<br>
> API?<br>
<br>
</div></div>Seems like an event would be a better solution. For example fire a<br>
'idlestatechange' event with the following API:<br>
<br>
interface IdleStateChangeEvent : Event<br>
{<br>
  const unsigned short AWAY;<br>
  const unsigned short ACTIVE;<br>
  const unsigned short IDLE;<br>
<br>
  readonly attribute unsigned short idleState;<br>
};<br>
<font color="#888888"><br>
/ Jonas<br>
</font></blockquote></div><br></div>
</div></div></blockquote></div><br></div>