- From: Michael Nordman <michaeln@google.com>
- Date: Mon, 31 Aug 2009 17:03:38 -0700
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>
Received on Monday, 31 August 2009 17:03:38 UTC