- From: Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
- Date: Sat, 16 Aug 2014 18:19:03 +0200
- To: Jonas Sicking <jonas@sicking.cc>, Mounir Lamouri <mounir@lamouri.fr>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Marcos Caceres <w3c@marcosc.com>
Jonas Sicking <jonas@sicking.cc> writes: > On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri <mounir@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 sure that they don't stomp on each >>> other's locks. Simply counting request() calls vs. release() calls >>> helps, but doesn't fully solve the problem. It's very easy to >>> accidentally call release too many times, in response to some UI >>> action for example. >>> >>> An alternative design would be something like >>> >>> x = new WakeLock("display"); >>> x.request(); >>> x.release(); >>> >>> Extra calls of either request() or release() are ignored, but pages >>> can create any number of WakeLocks of the same type. >> >> It seems that we already discussed using an object and this solution was >> dismissed because of this model being error-prone. > > Where was this discussed? Why was it considered more error prone? Was > it related to the patterns discussed at > > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297431.html > >> 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 appropriately. > > The problem arises when you have several semi-independent pieces of > code within a single page. Given that request() and release() is > likely going to happen in response to very different UI events or IO > events, it makes it fairly easy to accidentally have unbalanced calls. > > Consider for example a lock which is released either when a video > reaches its end, when the user presses the pause button, or when the > user close the <dialog> in which the video is rendered. It seems quite > easy to end up with a race where if the user close the <dialog> right > when the video ends, that release() would get called twice. Or if the > user pause the video first and then close the <dialog> that release() > would get called twice. Seems to me a declarative solution (like CSS) might be appropriate. @media screen { video:playing { wake-lock: display 15s; } } article.recipe:target { wake-lock: display; } -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
Received on Saturday, 16 August 2014 16:19:33 UTC