On Sat, 16 Aug 2014, at 08:40, Jonas Sicking wrote:
On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri mou...@lamouri.fr
wrote:
On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote:
I am however more worried about that only having a request() and a
release() function means that pages that
On Sat, Aug 16, 2014 at 9:19 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Jonas Sicking jo...@sicking.cc writes:
On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote:
I am however more worried about that
On Mon, Aug 18, 2014 at 2:04 AM, Mounir Lamouri mou...@lamouri.fr wrote:
It's also not clear
how this solution is superior than the current solution [1] with regards
to multiple releases or requests. In [1], if you call .request() or
.release() multiple time, the promise reacts
I think it'd be unfortunate if this API had just one shared lock per browsing
context and required components on the page to coordinate locking, but provided
no means to do so. This will force authors of libraries and components to
create dummy iframes just to have their private lock, and
WakeLock.request() expecting a string isn't very friendly to feature detection.
I'd prefer if individual lock types were instances of objects, e.g.
navigator.*Lock objects could be instances of a variant of the WakeLock
interface:
navigator.screenLock.request();
navigator.screenLock.isHeld();
My biggest concern with the WakeLock API is that it's easy to forget (or fail)
to release the lock.
It's not a problem with the API per se, but a programming problem in general:
resource management in non-trivial programs is hard. WakeLocks are especially
problematic in this regard, as a
On Mon, Aug 18, 2014 at 4:21 PM, Kornel Lesiński kor...@geekhood.net wrote:
My biggest concern with the WakeLock API is that it's easy to forget (or
fail) to release the lock.
It's not a problem with the API per se, but a programming problem in general:
resource management in non-trivial
On Monday, August 18, 2014 at 6:24 PM, Kornel Lesiński wrote:
I think it'd be unfortunate if this API had just one shared lock per browsing
context and required components on the page to coordinate locking, but
provided no means to do so.
The API allows scripts to check which locks
On Monday, August 18, 2014 at 7:21 PM, Kornel Lesiński wrote:
My biggest concern with the WakeLock API is that it's easy to forget (or
fail) to release the lock.
It's not a problem with the API per se, but a programming problem in general:
resource management in non-trivial programs is
In general I feel this thread has taken a turn for the complex. Why don't we
just do what other platforms do, and provide a simple global request/release
mechanism (or toggleable Boolean property!), which developers can build on top
of? A lot of the ideas here seem to be trying to create the
On Mon, Aug 18, 2014 at 5:10 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
In general I feel this thread has taken a turn for the complex. Why don't we
just do what other platforms do, and provide a simple global request/release
mechanism (or toggleable Boolean property!), which
On Monday, August 18, 2014 at 8:10 PM, Domenic Denicola wrote:
In general I feel this thread has taken a turn for the complex. Why don't we
just do what other platforms do, and provide a simple global request/release
mechanism (or toggleable Boolean property!), which developers can build
(sorry, accidental send before!)
On Monday, August 18, 2014 at 8:10 PM, Domenic Denicola wrote:
In general I feel this thread has taken a turn for the complex. Why don't we
just do what other platforms do, and provide a simple global request/release
mechanism (or toggleable Boolean
On Monday, August 18, 2014 at 6:41 PM, Kornel Lesiński wrote:
WakeLock.request() expecting a string isn't very friendly to feature
detection.
The API tells you if a wake lock type is not supported by either rejecting with
a TypeError or by a DOMException whose name is NotSupportedError.
On Mon, Aug 18, 2014 at 4:37 PM, Marcos Caceres w...@marcosc.com wrote:
while(navigator.wakeLock.isHeld(screen))
navigator.wakeLock.release(screen); // just release the damn thing in my
leaky code!
That would just halt the browser as the script would never complete:
currently releasing
On Mon, Aug 18, 2014 at 5:37 PM, Marcos Caceres w...@marcosc.com wrote:
On Monday, August 18, 2014 at 6:41 PM, Kornel Lesiński wrote:
WakeLock.request() expecting a string isn't very friendly to feature
detection.
The API tells you if a wake lock type is not supported by either rejecting
On Mon, Aug 18, 2014 at 5:35 PM, Marcos Caceres w...@marcosc.com wrote:
The reason I didn't make it a boolean was because of the IPC involved and
because I wanted to support multiple types of locks without needing to add
new attributes in the future (and if we need to add the complex stuff
On Monday, August 18, 2014 at 6:24 PM, Kornel Lesiński wrote:
I think it'd be unfortunate if this API had just one shared lock per
browsing context and required components on the page to coordinate locking,
but provided no means to do so.
The API allows scripts to check which locks
I'd prefer if individual lock types were instances of objects, e.g.
navigator.*Lock objects could be instances of a variant of the WakeLock
interface:
navigator.screenLock.request();
navigator.screenLock.isHeld();
navigator.cpuLock.request();
navigator.cpuLock.release();
19 matches
Mail list logo
