W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2014

Re: [whatwg] Proposal: Wake Lock API

From: Marcos Caceres <w3c@marcosc.com>
Date: Tue, 15 Jul 2014 15:51:42 -0400
To: "Jasper St. Pierre" <jstpierre@mecheye.net>
Message-ID: <etPan.53c5864f.1190cde7.8884@Marcoss-MacBook-Pro.local>
Cc: WHATWG <whatwg@lists.whatwg.org>, Ilya Bogdanovich <bogdanovichiy@yandex-team.ru>

On July 15, 2014 at 3:31:32 PM, Jasper St. Pierre (jstpierre@mecheye.net) wrote:
> Should the lock automatically be released if the user switches to a
> different tab or somehow makes the content unviewable?

Yes. But it could be automatically reapplied once the user switches back to the tab/window. This could happen transparently. 

> Should the web
> content know about this, or should it just silently think the lock is still
> being held?

Ideally, it should just be silent. 

> This might affect the timeout situation. It would be strange to
> be unable to lock or suspend due to some random map embedded in a Yelp page
> somewhere taking a lock.

The locks are fairly soft, at last for screen. But yes, for "system" locks that would suck. We might need to limit those somehow. 

> What about for cases like laptops where the user can force a suspend, like
> closing the lid? If the system is configured to lock or suspend the
> machine, should this prevent it?

No, in this case it could be notified that it has lost the lock.  

> Are there any tasks like instant messaging
> where users might want to have it inhibit suspend, and the user can still
> be notified of it because the system might make a sound? Should the web
> content be aware of this as well?

I think that's a different use case: That could be better suited for push notifications + service workers + the notification API. 

> I'm at least happy that the web doesn't have the "burning a CD" task that
> we had to deal with with our desktop. :) That was a messy set of edge cases
> to deal with.

Heh, I'm sure similar cases will come up in the future (e.g., 3D printing over serial port API).  
Received on Tuesday, 15 July 2014 19:52:08 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:21 UTC