[whatwg] HTML extension for system idle detection.

[David Bennett]

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/973eae30/attachment-0001.htm>