[whatwg] HTML extension for system idle detection.

This would be my inclination as well. I'm not entirely convinced that "every
web app should define their own idle timeout" is such desirable behavior
that we should build our API around it by forcing every caller to specify
their idle timeout - having a standard event that's fired with an exposed
state for apps that need it seems like a cleaner approach.
-atw

On Mon, Aug 31, 2009 at 5:03 PM, Michael Nordman <michaeln at google.com>wrote:

> 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/09373ddc/attachment.htm>

Received on Monday, 31 August 2009 17:30:30 UTC