[whatwg] HTML extension for system idle detection.

David Bennett ddt at google.com
Fri Aug 28 14:47:45 PDT 2009


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.


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.


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.


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)

interface WindowTimers {
// timers
long setSystemIdleCallback<http://www.w3.org/TR/html5/no.html#dom-windowtimers-settimeout>
(in TimeoutHandler <http://www.w3.org/TR/html5/no.html#timeouthandler> handler,
in long idleTimeoutSec);
long setSystemIdleCallback<http://www.w3.org/TR/html5/no.html#dom-windowtimers-settimeout>
(in TimeoutHandler <http://www.w3.org/TR/html5/no.html#timeouthandler> handler,
in long idleTimeoutSec, arguments...);
long setSystemIdleCallback<http://www.w3.org/TR/html5/no.html#dom-windowtimers-settimeout>(in
DOMString code, in long idleTimeoutSec);
long setSystemIdleCallback<http://www.w3.org/TR/html5/no.html#dom-windowtimers-settimeout>(in
DOMString code, in long idleTimeoutSec, in DOMString language);
void clearSystemIdleCallback<http://www.w3.org/TR/html5/no.html#dom-windowtimers-cleartimeout>(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


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.


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.


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.

Questions, Comments, etc.
What do others think of this addition? Does anyone have an idea for a better
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090828/e27ddb4e/attachment-0002.htm>

More information about the whatwg mailing list