Can I suggest the following approach to wake lock interface:
1. User agent provides an interface to documents such that a document loaded
into the browsing context can indicate whether it wishes to keep the device
awake. Each browsing context has an independent state of this flag.
2. User agent
On 2014/07/15 12:21, Marcos Caceres wrote:
## Use cases
...
Note that some devices have a stay-awake-while-held feature that solves
the problem for many of the suggested use cases such as reading a book.
For others, such as maps while driving, the trend towards connecting
devices to the
On Tue, Aug 19, 2014 at 1:29 PM, Marcos Caceres w...@marcosc.com wrote:
interface WakeLock : EventTarget {
Promisevoid request();
Promisevoid release();
attribute EventHandler onlost;
}
What are the use cases for onlost?
Though I don't really mind exposing this state. My experience
On Wed, Aug 20, 2014 at 10:29 AM, Jonas Sicking jo...@sicking.cc wrote:
FWIW, the web platform sorely needs a construct for readonly state
variable + event whenever the state changes. I.e. some form of
observable which remembers the last produced value. I had hoped the
Streams would get us
On Wed, Aug 20, 2014 at 1:33 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Aug 20, 2014 at 10:29 AM, Jonas Sicking jo...@sicking.cc wrote:
FWIW, the web platform sorely needs a construct for readonly state
variable + event whenever the state changes. I.e. some form of
observable which
On 08/20/2014 11:33 AM, Anne van Kesteren wrote:
On Wed, Aug 20, 2014 at 10:29 AM, Jonas Sicking jo...@sicking.cc wrote:
FWIW, the web platform sorely needs a construct for readonly state
variable + event whenever the state changes. I.e. some form of
observable which remembers the last produced
On Wednesday, August 20, 2014 at 5:15 AM, Olli Pettay wrote:
On 08/20/2014 11:33 AM, Anne van Kesteren wrote:
On Wed, Aug 20, 2014 at 10:29 AM, Jonas Sicking jo...@sicking.cc
(mailto:jo...@sicking.cc) wrote:
FWIW, the web platform sorely needs a construct for readonly state
On Wed, Aug 20, 2014 at 5:09 PM, Marcos Caceres w...@marcosc.com wrote:
And of course Object.observe would work really nicely, but I've been told a
bunch of times by various people that we can't use Object.observe on DOM APIs
(this *really* sucks).
Not by default, but we can make it work as
On Wednesday, August 20, 2014 at 11:14 AM, Anne van Kesteren wrote:
On Wed, Aug 20, 2014 at 5:09 PM, Marcos Caceres w...@marcosc.com
(mailto:w...@marcosc.com) wrote:
And of course Object.observe would work really nicely, but I've been told a
bunch of times by various people that we
On Tue, 19 Aug 2014, at 04:54, Jonas Sicking wrote:
Note that in the API that I'm proposing, there is no way to
accidentally rely on GC behavior. If a WakeLock object is GCed before
it has been release()ed, then the lock is held indefinitely (until the
user leaves the page of course).
I.e.
On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Tue, 19 Aug 2014, at 04:54, Jonas Sicking wrote:
Note that in the API that I'm proposing, there is no way to
accidentally rely on GC behavior. If a WakeLock object is GCed before
it has been release()ed, then the lock
Tab Atkins Jr. jackalm...@gmail.com writes:
On Sat, Aug 16, 2014 at 9:19 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
[…]
Seems to me a declarative solution (like CSS) might be appropriate.
@media screen {
video:playing {
wake-lock: display 15s;
}
}
On August 19, 2014 at 11:16:19 AM, Nils Dagsson Moskopp
(n...@dieweltistgarnichtso.net) wrote:
Tab Atkins Jr. writes:
This solves the GC and locking issues (the latter by delegating state
management to CSS, which everyone already knows to use).
It would also make it easily possible to
On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Tue, 19 Aug 2014, at 04:54, Jonas Sicking wrote:
Note that in the API that I'm proposing, there is no way to
accidentally rely on GC behavior. If a WakeLock object is GCed before
it has been release()ed, then the lock
On Tue, Aug 19, 2014 at 11:07 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri mou...@lamouri.fr wrote:
How would you handle feature detection with this design?
This is a good question. I don't have a better solution than adding
separate
On August 19, 2014 at 2:08:04 PM, Jonas Sicking (jo...@sicking.cc) wrote:
How would you handle feature detection with this design?
This is a good question. I don't have a better solution than adding
separate DisplayWakeLock() and SystemWakeLock() classes.
Might make sense to do
On Tue, Aug 19, 2014 at 1:29 PM, Marcos Caceres w...@marcosc.com wrote:
On August 19, 2014 at 2:08:04 PM, Jonas Sicking (jo...@sicking.cc) wrote:
How would you handle feature detection with this design?
This is a good question. I don't have a better solution than adding
separate
On August 19, 2014 at 4:39:03 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote:
Why is isHeld still used here? You don't need it to avoid squashing
someone else's lock with this design, and several people have
pointed out that exposing it is a footgun, as people might check it and
On Tue, Aug 19, 2014 at 1:44 PM, Marcos Caceres w...@marcosc.com wrote:
On August 19, 2014 at 4:39:03 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote:
Why is isHeld still used here? You don't need it to avoid squashing
someone else's lock with this design, and several people have
pointed out
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
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 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 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
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 only having a request() and a
release() function means that pages that contain multiple
Den 14-08-2014 kl. 23:02 skrev Jonas Sicking:
On Thu, Aug 14, 2014 at 9:55 AM, Jesper Kristensen
m...@jesperkristensen.dk wrote:
Hi
Would it make sense to tie the system lock to a notification?
For example:
new Notification(Processing..., {tag: abc, progressBar: 0.8, wakeLock:
system});
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 contain multiple independent
subsystems will have to make sure that they don't stomp on each
other's locks. Simply counting request()
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 contain multiple independent
subsystems will have to make
On Wed, Aug 13, 2014 at 9:46 PM, Biju bijumaill...@gmail.com wrote:
On 13 August 2014 21:00, Jonas Sicking jo...@sicking.cc wrote:
An alternative design would be something like
x = new WakeLock(display);
x.request();
x.release();
Extra calls of either request() or release() are ignored,
On 14 August 2014 03:07, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 13, 2014 at 9:46 PM, Biju bijumaill...@gmail.com wrote:
On 13 August 2014 21:00, Jonas Sicking jo...@sicking.cc wrote:
An alternative design would be something like
x = new WakeLock(display);
x.request();
Jonas Sicking jo...@sicking.cc writes:
On Thu, Jul 17, 2014 at 7:17 AM, Marcos Caceres w...@marcosc.com wrote:
On Thursday, July 17, 2014 at 6:12 AM, Mounir Lamouri wrote:
On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote:
I don't have a strong opinion. My concern was mostly about
Hi
Would it make sense to tie the system lock to a notification?
For example:
new Notification(Processing..., {tag: abc, progressBar: 0.8,
wakeLock: system});
There are many myths and rumors about how to conserve battery on mobile
devices. A small improvement could be to require apps to
On Thu, Aug 14, 2014 at 4:44 AM, Biju bijumaill...@gmail.com wrote:
So what happens when we have following function call.
How do we release the runaway lock request.
Another case is a page made lock and user navigate away from the page.
Do the browser keep the lock for ever ?
function
On Thu, Aug 14, 2014 at 6:33 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
So what would happen if I want my laptop to go to into low-power mode by
closing the lid? Would I have to close a lot of risky web pages first?
We need indeed something to prevent abuse here. Especially
On Thu, Aug 14, 2014 at 9:55 AM, Jesper Kristensen
m...@jesperkristensen.dk wrote:
Hi
Would it make sense to tie the system lock to a notification?
For example:
new Notification(Processing..., {tag: abc, progressBar: 0.8, wakeLock:
system});
There are many myths and rumors about how to
Additionally in the browser UI, if user can get a way to find which
tabs/pages are locking the system/display it will be great help.
On Thu, Jul 17, 2014 at 7:17 AM, Marcos Caceres w...@marcosc.com wrote:
On Thursday, July 17, 2014 at 6:12 AM, Mounir Lamouri wrote:
On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote:
I don't have a strong opinion. My concern was mostly about developers
having to watch for a whole bunch
On 15 July 2014 15:51, Marcos Caceres w...@marcosc.com wrote:
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
On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote:
On Wednesday, July 16, 2014 at 5:59 AM, Mounir Lamouri wrote:
On Wed, 16 Jul 2014, at 05:21, Marcos Caceres wrote:
I do not think we should have this timeout option. That sounds like a
very week use case and something fairly easy
On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote:
On Wednesday, July 16, 2014 at 5:59 AM, Mounir Lamouri wrote:
On Wed, 16 Jul 2014, at 05:21, Marcos Caceres wrote:
I do not think we should have this timeout option. That sounds like a
very week use case and something
On Thursday, July 17, 2014 at 6:12 AM, Mounir Lamouri wrote:
On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote:
I don't have a strong opinion. My concern was mostly about developers
having to watch for a whole bunch of different interaction queues (touch
events, mouse events, focus
On Wed, 16 Jul 2014, at 05:21, Marcos Caceres wrote:
### Timeouts
We are thinking of adding a dictionary to hint at the system the amount
of time it should hold the lock for (in ms). So, then the developer can
express holding the lock for 5 minutes (e.g., ebook case, instead of
having to
On Wednesday, July 16, 2014 at 5:59 AM, Mounir Lamouri wrote:
On Wed, 16 Jul 2014, at 05:21, Marcos Caceres wrote:
I do not think we should have this timeout option. That sounds like a
very week use case and something fairly easy to do with the tools the
platform already provides. The
## Use cases
A website wants the prevent a device from entering a power-saving state to
allow a user to complete a task where it's not practical for the user to touch
the screen (e.g., a maps application while driving, a VR headset like
Cardboard).
A website needs to be able to complete a
Should the lock automatically be released if the user switches to a
different tab or somehow makes the content unviewable? Should the web
content know about this, or should it just silently think the lock is still
being held? This might affect the timeout situation. It would be strange to
be
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
48 matches
Mail list logo
