- From: Marcos Caceres <w3c@marcosc.com>
- Date: Tue, 15 Jul 2014 15:51:42 -0400
- To: "Jasper St. Pierre" <jstpierre@mecheye.net>
- 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