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

Reply via email to