[whatwg] HTML extension for system idle detection.

[Jonas Sicking]

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

Seems like an event would be a better solution. For example fire a
'idlestatechange' event with the following API:

interface IdleStateChangeEvent : Event
{
  const unsigned short AWAY;
  const unsigned short ACTIVE;
  const unsigned short IDLE;

  readonly attribute unsigned short idleState;
};

/ Jonas