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>
<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 class="h5">On Fri, Aug 28, 2009 at 2:47 PM, David Bennett<<a href="mailto:ddt@google.com">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>