On July 15, 2014 at 3:31:32 PM, Jasper St. Pierre (jstpie...@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).