[whatwg] HTML extension for system idle detection.

[David Bennett]

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/20090901/9538f174/attachment-0002.htm>