[whatwg] HTML extension for system idle detection.

[Thomas Broyer]

On Fri, Aug 28, 2009 at 11: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.

Other use cases:
 - disconnect from server-push (close WebSocket, stop polling, etc.)
to later reconnect when the user is back (GTalk seems to do something
similar: it unsubscribes from XMPP's GMail notifications when you're
away, and "re-sync" when you're back to show you which mails arrived
while you were away); this would save client-side processing –in
GMail, Google Reader, Facebook, Twitter, etc. no need to poll for new
mail/entry/news/tweet and update the UI when nobody's there to see it–
*and* network traffic
 - automatically logout the user from a webapp; real example: our
client wants us to automatically logout the user if idle for 30
minutes, we're currently using a timer that we re-initialize at each
action in the app (we could use window.onblur/onfocus or similar but
if you just go away from your computer, the app can still be focused
so it wouldn't work "reliably"). We told them that they'd rather lock
the Windows session (which wouldn't be equivalent to our timer, but
more user-friendly IMO) because they actually expressed a concerned
about privacy of the data stored in the app, so it'd be more about
being away than being idle; but that wasn't an acceptable solution for
them...

> 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

See also (could serve as an inspiration):
http://help.adobe.com/en_US/AIR/1.5/jslr/flash/desktop/NativeApplication.html#idleThreshold
http://help.adobe.com/en_US/AIR/1.5/jslr/flash/desktop/NativeApplication.html#timeSinceLastUserInput
http://help.adobe.com/en_US/AIR/1.5/jslr/flash/desktop/NativeApplication.html#event:userIdle
http://help.adobe.com/en_US/AIR/1.5/jslr/flash/desktop/NativeApplication.html#event:userPresent

-- 
Thomas Broyer