- From: David Bennett <ddt@google.com>
- Date: Fri, 28 Aug 2009 14:47:45 -0700
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<http://www.w3.org/TR/html5/browsers.html#window>] 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 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<http://www.w3.org/TR/html5/no.html#timeouthandler> 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090828/e27ddb4e/attachment-0001.htm>
Received on Friday, 28 August 2009 14:47:45 UTC