[whatwg] HTML extension for system idle detection.

[Michael Nordman]

This would be a nice addition... seems like an event plus a read-only
property on the 'window' object could work.
window.idleState;
window.onidlestatechange = function(e) {...}


On Fri, Aug 28, 2009 at 3:40 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090831/98b69fa6/attachment-0001.htm>