[whatwg] HTML extension for system idle detection.

[Jeremy Orlow]

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.

This makes it sound like chat is the only use case.  I'd say something
like "for example" to make it more clear.

> 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.

Another is that a WebApp could use this as a time to garbage collect
and/or sync stuff stored in localStorage/database

> WORK AROUNDS
>
> The idle state of the user is currently detected by looking at the brower

browser

> 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]

2 minutes is an example, right?

> * Any jitter intentionally added to the idle times reported [1]

Idle times are no longer reported directly, but some jitter should
probably still be allowed.

> * The granularity of the times reported (e.g. a UA may round them to multiples of 15 seconds)

There no longr is any concept of granularity, right?

> [NoInterfaceObject, ImplementedOn=Window] interface WindowTimers {
> // timers

What's this for?

> // Returns the current system idle state.
> int systemIdleState();
> // The event fired when the idle state of the system changes.

Closing } ?

So is systemIdleState the name of the event?  If so, onidle (or
something like that) seems much more in line with other events.

> 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

Spelling

> 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

Spelling

> the jitter and granularity aspects of the idle detection.
> http://portal.acm.org/citation.cfm?id=1267637

Note that this is MUCH less relevant with the current design.  Maybe
the wording should be changed a bit to reflect this.

Overall, this looks pretty good.  I guess you should wait a bit to see
if anyone else here has any comments, but as Ian mentioned,
public-webapps is the better audience for this proposal.

J