[whatwg] HTML extension for system idle detection.

[David Bennett]

Actually, one small change.  I think I need the idle time in seconds in the
event, in case different UAs implement different idles as their minimum
time.
// The event fired when the idle state of the system changes.
interface IdleStateChangeEvent : Event
{
 const unsigned short AWAY;
 const unsigned short ACTIVE;
 const unsigned short IDLE
;

 readonly attribute unsigned short idleState;
 readonly attribute unsigned long idleTimeInSec;
};

This way the js can find the actual time and do a timer event to get the
idle time it is looking for.

Thanks,
David.

On Tue, Sep 15, 2009 at 5:13 PM, David Bennett <ddt at google.com> wrote:

> Morning,
> Updated the document for the proposal which now uses an event callback for
> the system idle along with a method to get the current system idle time.
>
> Comments on the update proposal?
>
> Thanks,
> David.
>
> 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 enables an event for the minimum idle timeout and
> has a query to determine the current system idle.  The event is fired when
> the state changes.  Active->idle, Active->away, idle->away, idle->active,
> away->active.
>
> The idle times are all specified in seconds, the event will be fired when
> the idle state changes.
>
> Not explicitly specified, and thus intentionally left to the UA, include:
> * The event will be fired after the minimum system idle time for the
> property; 2 minutes. [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
> // Returns the current system idle state.
> int systemIdleState();
>
> // The event fired when the idle state of the system changes.
> interface IdleStateChangeEvent : Event
> {
>  const unsigned short AWAY;
>  const unsigned short ACTIVE;
>  const unsigned short IDLE;
>
>  readonly attribute unsigned short idleState;
> };
>
> 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.
>
> 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
>
>
> On Tue, Sep 1, 2009 at 4:33 PM, David Bennett <ddt at google.com> wrote:
>
>> On Tue, Sep 1, 2009 at 4:26 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
>>
>>> On Tue, Sep 1, 2009 at 3:53 PM, Mike Wilson <mikewse at hotmail.com> wrote:
>>>
>>>>  David Bennett wrote:
>>>>
>>>>  On Mon, Aug 31, 2009 at 5:30 PM, Drew Wilson <atwilson at google.com>wrote:
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> The trouble with this is it doesn't allow any experimentation on the
>>>> part of the app/entity to figure out what is the best idle time for it's
>>>> purposes.  In terms of chat it might be that a 3 minute or 5 minute idle
>>>> time works best in terms of people's attention.  For something like watching
>>>> a video perhaps a 15 minute idle would be a better length of time, or for an
>>>> online game a longer idle time is probably useful before being signed out.
>>>>  Different purposes have different requirements for the idle time so it
>>>> makes sense to allow them to specify the different timeouts.
>>>>
>>>> This requirement could be solved in several other ways, f ex making sure
>>>> that the "standard" timeout period is short enough to not be longer than
>>>> what any app wants. Then (as was previously suggested) an app that wants a
>>>> longer timeout can do setTimeout and trigger its own idle stuff if status
>>>> has not come back to "active" during that time.
>>>>
>>>
>>> If we went the route of using events, I definitely think this is the way
>>> to go.  Since the originally proposed API was based off of the timer API,
>>> you're really only adding one step if you want that behavior.  Having a
>>> globally configured value seems sloppy and you'll have to manually use
>>> timeouts if, for example, you were using 2 libraries that used it for
>>> different purposes and thus wanted different idle timeouts.
>>>
>>
>> I have been thinking about this.  I think this sounds reasonable too,
>> perhaps we should specify a minimum idle event timeout?  For example make
>> the event fire after 2 minutes idle?  Be easy to hook up to the property
>> without a timeout to see if the user is still idle after this time.
>>
>>
>>>
>>>
>>>> Another alternative is to have no event, and just a property:
>>>>     window.lastUserActionTime
>>>> which is kept updated with the "msec since epoch" for the latest user
>>>> input on the desktop. Then an app can implement its own idle functionality
>>>> with totally own rules. This API has the drawback of maybe exposing too much
>>>> information (the rate of input events to other apps), but may spawn some
>>>> ideas.
>>>>
>>>
>>> Then you're poling, which seems pretty ugly.  I'd much prefer events to
>>> this.
>>>
>>> 2009/8/31 Max Romantschuk <max at romantschuk.fi>
>>>>
>>>> One issue:
>>>>
>>>
>>>> Is the user idle when the tab is in the background, when the browser is
>>>> in the background, or when the user is away from the machine? These are all
>>>> distinct cases of different levels of "idleness", and it's largely depended
>>>> on the use case which kind of "idleness" makes sense for a particular
>>>> application.
>>>>
>>>
>>> I would argue that "when the browser is in the background" should be no
>>> different from "when the tab is in the background".  Given that the
>>> information the system uses to determine idleness (mouse movements and such)
>>> are all available to a web app while it's in the foreground tab, it seems as
>>> though knowing the idle time just from the perspective of your tab is not
>>> terribly useful.  So, to me, I think it's pretty clear this should be system
>>> wide idleness.
>>>
>>
>> Yes, I agree idlessness form being in the background should be a different
>> event/information if it is supported.
>>
>> I will update my document with these ideas and then repost.
>>
>> Thanks,
>> David.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090915/2ff2bee7/attachment-0002.htm>