- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 28 Aug 2009 15:40:18 -0700
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
Received on Friday, 28 August 2009 15:40:18 UTC