New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Implement WakeLock API

Project Member Reported by adan...@google.com, Jul 5 2013

Issue description

Steps to reproduce the problem:
1. Lock phone orientation to portrait
2. Go to http://ball-puzzle.appspot.com/
3. Press 'Start' and play the ball puzzle game

What is the expected behavior?
Should be able to play as long as possible and see the content.

What went wrong?
After a short while, the Android Screen Saver kicks in and you have to touch the screen to stop it locking the display. There should be an API to disable the screen saver - possibly gated on having a listener to the device orientation event registered, and motion activity.

Did this work before? No 

Chrome version: 27.0.1453.111  Channel: n/a
OS Version: 4.2
Flash Version: 

Native Android lets you do this with a wake lock.


 

Comment 1 by peter@chromium.org, Jul 9 2013

Cc: kenneth....@intel.com joh...@chromium.org
Labels: Cr-Blink
Status: Available
This is an interesting idea, and I can see why we'd want this.  Applications can receive other forms of input than touch, whereas only touch will prevent the device from sleeping after N seconds.

Do we really need an API for this, however?  I wonder if it'd be enough to consider this as an implementation detail -- all forms of input (i.e. motion above a certain threshold, camera/microphone streams) can be considered in keeping the device alive.  What benefit would having a separate API for this have?

Comment 2 by peter@chromium.org, Jul 9 2013

Cc: peter@chromium.org
This would be useful on desktop too, for apps like YouTube and video Hangouts where you might not use the mouse or keyboard for an extended period of time.

On Android we'd implement this using FLAG_KEEP_SCREEN_ON[1].

We'd have to be careful though, as we've seen from Android apps that developers often misuse wake locks.

Doing it automatically would be cool, but getting the right thresholds sounds tricky. For example for the camera stream example, the ideal threshold probably involves doing face detection and checking whether the user is still there, but that sounds like overkill.

[1]: http://developer.android.com/reference/android/view/WindowManager.LayoutParams.html#FLAG_KEEP_SCREEN_ON

Comment 4 by smus@chromium.org, Aug 17 2013

Cc: smus@chromium.org

Comment 5 by klo...@chromium.org, Nov 18 2013

Cc: klo...@chromium.org
We are already doing this for video, WebRTC. Maybe we just need to extend it.

Comment 6 by sethladd@google.com, May 15 2014

Possible dupe of https://code.google.com/p/chromium/issues/detail?id=372443 ?

Grace, would definitely use the ability to turn off the screensaver/auto-logout/dimming. See Issue #372443 for another use case.

Comment 7 by klo...@chromium.org, May 15 2014

I am ok to keep the screen on when the current tab has device orientation listener.

Peter/John, want to get it in?

Comment 8 by ojan@chromium.org, May 17 2014

I don't see what having a device orientation listener has to do with disabling the screen lock. Also, historically, there's been a lot of resistance to having adding event listeners have side effects.

We should just provide a proper dedicated API for this IMO.

Comment 9 by klo...@chromium.org, May 19 2014

It is OK if we add a API. We may need user permission to use it.

Comment 10 by ojan@chromium.org, May 21 2014

Cc: slightlyoff@chromium.org
Hi guys,

Me and my team from Yandex just started work on this API at our browser, which I believe you know, based on top of Chromium. Would you mind if we implement it in Chromium/Blink too?

Comment 12 by peter@chromium.org, May 30 2014

Definitely!

All contributions are very much welcomed, so it's great if you're happy to pick this up :-).
Cc: mlamouri@chromium.org
Summary: Need an API to disable screen lock (was: Need an API to disable screen saver)
Labels: -OS-Android OS-All OWP-Type-NewAPI
Summary: Implement WakeLock API (was: Need an API to disable screen lock)
Current specification is here: http://w3c.github.io/wake-lock/
Issue 372443 has been merged into this issue.

Comment 17 by pdr@chromium.org, Jul 28 2015

Cc: alogvi...@yandex-team.ru redche...@yandex-team.ru bogdanov...@yandex-team.ru
Is there any progress on this?

For a personal project over the weekend (growing crops indoors with targeted lighting) I tried using this API and found the implementation sort of stalled.
We've been making progress regarding the Blink part recently: https://codereview.chromium.org/1084923002/
Project Member

Comment 19 by bugdroid1@chromium.org, Oct 30 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5

commit f50445a583e4b7f5f4c865a061c83a4d7b57e5c5
Author: alogvinov <alogvinov@yandex-team.ru>
Date: Fri Oct 30 13:00:12 2015

Reland of Wake Lock API implementation (Chromium part)

Original issue: https://codereview.chromium.org/1107333002/

Original issue description:

Wake Lock API implementation (Chromium part)

This is Chromium part of Wake Lock API implementation as per specification:
http://www.w3.org/TR/wake-lock/

The corresponding Blink part is submitted in issue 1084923002

Design document: https://docs.google.com/document/d/1KbIENP0wgxtSXDQFn9PbHZ_tAKZfR1Y8u4Hst8LpeaA/edit?usp=sharing

R=tsepez@chromium.org
R=nasko@chromium.org
R=mlamouri@chromium.org
R=jochen@chromium.org

BUG=257511

Review URL: https://codereview.chromium.org/1393203004

Cr-Commit-Position: refs/heads/master@{#357087}

[modify] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/browser/frame_host/render_frame_host_delegate.cc
[modify] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/browser/frame_host/render_frame_host_delegate.h
[modify] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/browser/frame_host/render_frame_host_impl.cc
[add] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/browser/wake_lock/wake_lock_browsertest.cc
[add] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/browser/wake_lock/wake_lock_service_context.cc
[add] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/browser/wake_lock/wake_lock_service_context.h
[add] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/browser/wake_lock/wake_lock_service_context_unittest.cc
[add] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/browser/wake_lock/wake_lock_service_impl.cc
[add] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/browser/wake_lock/wake_lock_service_impl.h
[modify] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/browser/web_contents/web_contents_impl.cc
[modify] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/browser/web_contents/web_contents_impl.h
[modify] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/common/BUILD.gn
[add] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/common/wake_lock_service.mojom
[modify] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/content_browser.gypi
[modify] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/content_common_mojo_bindings.gyp
[modify] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/content_renderer.gypi
[modify] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/content_tests.gypi
[modify] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/renderer/render_frame_impl.cc
[modify] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/renderer/render_frame_impl.h
[add] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/renderer/wake_lock/wake_lock_dispatcher.cc
[add] http://crrev.com/f50445a583e4b7f5f4c865a061c83a4d7b57e5c5/content/renderer/wake_lock/wake_lock_dispatcher.h

For my use case, I would need the API as opposed to simply tying into device motion or some other event. 

In my app a presenter interacts with the page while multiple viewers have their interface controlled via commands sent from the presenter to the participants via websockets. The viewer just follows along going with the presenter.

Streaming video may be redundant or network prohibitive. A couple of bytes via websocket is much lighter than HD video stream.
I need this for an application that renders content in a canvas and WebRTC audio-only.
Current wakelock triggers of Webcam access and video are not enough.
I just tried the experimental API implementation, and on Mac OSX at least, it seems to prevent the screen from sleeping, but not the screen saver from kicking in, unlike the builtin wakelock of webcam access or video playback.
Same as butler.matthew I am using websockets to control lyrics and score for those playing in a band. So detecting video, audio, orientation does not help. 
I'm also looking for this capability in a web application I'm writing which uses the Web MIDI API in Chrome for Android. The user connects a MIDI instrument to the device and uses MIDI events as input, but the screen dims and turns off soon after they begin using it. In the meantime, I'll have to use a solution which abuses a <video> element instead.
Cc: miguelg@chromium.org tedc...@chromium.org
 Issue 454735  has been merged into this issue.
Components: -Blink Blink>DOM

Comment 27 by tkent@chromium.org, Feb 29 2016

Components: -Blink>DOM Blink
Labels: Hotlist-BlinkNoLabel

Comment 28 by tkent@chromium.org, Apr 27 2016

Labels: -Hotlist-BlinkNoLabel Hotlist-BlinkNoComponent
Project Member

Comment 29 by sheriffbot@chromium.org, Jun 17 2016

Labels: Hotlist-Google

Comment 30 by addyo@chromium.org, Jun 24 2016

Labels: Hotlist-DevRel
Looking at https://w3c.github.io/wake-lock/ it appears there's been some further movement on the spec front. Do we know if there are plans to continue working on this from the Chromium front over the next quarter or two?
The only change that invalidates the current implementation is addition of same-origin requirement for nested frames. I can make the necessary changes in the implementation. Is there an issue for that already, or should I create one?
Labels: -Pri-2 Pri-3
I'm not aware of an issue for it.

For the sake of transparency, work in Chrome on this feature generally stopped last year due to some people raising concern over users not realizing the screen is being kept alive, resulting in the battery being drained in some cases.

At the time we were deeply focused on battery life and thus there wasn't enough motivation to keep the project moving from our end. I hoped we would return to the idea at a later date, so please don't interpret this as Chrome being fundamentally opposed, it was just de-prioritized for those reasons.

Apologies for the lack of clear external communication about that at the time.

Additionally, the current feature is polyfillable via a hidden video so the priority wasn't regarded as high.

I hope that's helpful.

To me it sounds reasonable to complete the implementation so the feature can be enabled in chromium-based browsers, and we can simultaneously re-open the discussions around including it in Chrome given the UX/power considerations.
Components: -Blink Blink>Input

Comment 34 by addyo@chromium.org, Jul 10 2016

@alogvinov@yandex-team.ru, do you want to go ahead and create an issue for same-origin requirement for nested frames? I think as Owen mentions it would be useful for other Chromium browsers to enable this feature once ready and we can then chase the rest of this up on the Chrome side.
@addyo yes I do, when my work priorities permit. I hope to have it done soon.
Owner: alogvi...@yandex-team.ru
Status: Assigned (was: Available)
@ #32 Are you sure using <video/> is the way to go to emulate that functionality ? I've implemented it and I feel like an evil marketer doing so.

Having a way to keep web page/PWA awake would be nice, specially for Geolocation like it's been done on FirefoxOS https://developer.mozilla.org/en-US/docs/Mozilla/B2G_OS/API/Wake_Lock_API/Keeping_the_geolocation_on_when_the_application_is_invisible .

In my case I use WebSocket + Geolocation + ServiceWorker with a PWA. Without the <video/> hack the WebSocket connection is closed, but still, Geolocation is also disabled (but that's another ticket https://bugs.chromium.org/p/chromium/issues/detail?id=383125#c52 )

Anyway, all of that to say that with PWA, it'd make sense to reconsider some decisions. Concretely, the case looks like this :

- user launches the PWA and subscribes to geo-channels/geo-topics ; 
- user locks the phone screen ;
- the PWA uses Geolocation.watchPosition to acquire position ;
- the Geolocation is sent fast via permanent WebSocket connection ;
- the server replies with the relevant contextual geo-data ;
- the data is displayed in real-time on the user locked phone screen using Notification API (without Push API) ;
- the user get the relevant info out-of-the pocket without having to unlock the phone and to select the PWA, but simply by toggling the screen display button, and can therefore take immediate decision.

My comment might appear slightly off-topic, but it's to give some context with a concrete example (which could be a generic pattern for geo-pubsub PWA).

Cheers

Comment 38 by mkhah...@gmail.com, Mar 11 2017

@ #c5 
Agree. In a voice conversation based on WebRTC(audio only), the screen turns off and after a couple of minutes the stream is dropped. I think the wakelock needs to be extended to include also the audio.
Cc: hta@chromium.org owe...@chromium.org
Components: Blink>WebRTC
The predictability program is reviewing the top 50 starred Blink bugs this quarter, and this is 39 on that list.  We’re hoping that for each we can either close it, set an owner and target milestone, or set a NextAction date so that we know when to check back in.

The WebRTC audio use case here is interesting.  hta@ any thoughts?

alogvinov@ is this still something you're planning on working on?

owencm@ the PWA argument seems potentially compelling to me.  Any updated thinking from the capabilities program on this?  Given that this is already possible via a hidden video, I think the abuse concern is actually a counter-argument.  Better to have people use an explicit API which we have some hope of creating alternate policy/UX around if needed then push them to hidden videos where abuse may not be something we can mitigate without causing more serious web compat problems.
Cc: -joh...@chromium.org
I agree, and believe we should attempt to make progress on this.

Jumping back in here, what is the engineering status here? Is anyone interested in working on this?

I'm happy to work on this from a PM perspective and get UI / security / privacy consensus, although my bandwidth for these launches will increase after 61, so it may have to wait until then from my side.
The spec https://www.w3.org/TR/wake-lock/ has recently been reworked substantially so the implementation should be updated accordingly. I would like to continue working on the implementation but unfortunately I cannot guarantee any specific timeline due to my other high-priority tasks. I will probably have time to work on it starting from mid-April this year.
Sounds good, I'll ask around the Chrome team to assess views about what UI / security / privacy concerns there are and determine if there is a plausible path here to us shipping.
Blocking: 707868
Cc: rbyers@chromium.org
In chatting with klobag@ about this we agree we should be carefully introducing an explicit API at the same time as fixing the loophole that people are relying on (issue 707868).

klobag@ suggests that we could start by shipping a simple version of the API that works only in fullscreen mode (since fullscreen already requires a user gesture and is a clear visual indication that the page is actively using the screen).  What fraction of the usage in practice would that address?
alogvinov, if you're interested in moving this forward, roughly in April, great. If you know it will take longer, a Google team may be motivated to act sooner.

Comment 46 by dougt@chromium.org, Apr 12 2017

Components: Blink>WakeLock
Any ETA? I need it for my project.
What current status of it? Any progress?
alogvinov, do you still plan to work on implementing this api? If not, I would like to take up this work and finish rest of the implementation from now on.

Comment 50 by hta@chromium.org, Nov 8 2017

Cc: guidou@chromium.org
Adding guidou, who has more intimate audio API experience.

@mrunal yes you can take up the work, thank you for volunteering. Due to priorities I don't have a lot of time to invest into the implementation but I hope I can still be helpful.
Owner: mrunal.k...@intel.com
Thanks alogvinov. I will reach out to you if I need any help.
Ping.
I've just pushed the patch for review here,
https://chromium-review.googlesource.com/c/chromium/src/+/918062/5
Labels: Hotlist-Partner-GSuite
There is also a request from G Suite to support this, see here for more details: https://docs.google.com/document/d/1gNtE2ouO03dL6SiFCHJMz7xwyiebFAqFk-WMjDrJd6o/edit
Labels: OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows
Status: Started (was: Assigned)
FWIW, although there's still contention on how best to enable this functionality on mobile in a way that won't be prone to abuse / user surprise, there are some legitimate desktop-only use cases (like preventing monitor power saving when presenting slides) which I think should be non-controversial.  Chatting with mlamouri, we think this should be something we can ship desktop-first while trying to resolve the mobile tradeoffs in parallel.
As far as I understand, people already use hacks to accomplis something like a wakelock on mobile, by using a few tricks, like a 1x1 px video playing on iOS (I don't remember the exact details)

Eg. github.com/richtr/NoSleep.js

Which of course isn't good for battery usage.
Blockedon: 862460
wakelock is very important on mobile for gps navigation / geofencing. Today we have PWA to develop apps. But without wakelock features many kind of apps can't be realised (games, geofence tools, navigation apps, etc.) It's true battery usage is higher. But why not ask user to allow the wakelock in the same way user is asked to use geolocation?
Blockedon: 872530
Blockedon: 872535
Blockedon: 873030
Project Member

Comment 64 by bugdroid1@chromium.org, Aug 17

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599

commit a4fd427d8a3b82bd55cd9d64c480d5d610d9c599
Author: Mrunal Kapade <mrunal.kapade@intel.com>
Date: Fri Aug 17 23:39:15 2018

Wake Lock API: Implement Screen WakeLock based on Promises.

This patch implements navigator.getWakeLock(WakeLockType) and other
necessary interfaces such as WakeLock and WakeLockRequest to provide
acesss to Screen wakelock for now. Latest WakeLock API spec can be
seen here, https://www.w3.org/TR/wake-lock.

Intent to Implement,
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/KMNZmMF1_H4

Bug: 257511
Change-Id: I7fa4d0f7f287d7497b48f583e18e0ca5ca39e662
Reviewed-on: https://chromium-review.googlesource.com/918062
Commit-Queue: Mrunal Kapade <mrunal.kapade@intel.com>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584239}
[modify] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/WebKit/LayoutTests/TestExpectations
[delete] https://crrev.com/e6a59a6bf0c44a45fabe15389cd29373325eb4e8/third_party/WebKit/LayoutTests/external/wpt/wake-lock/idlharness.https.window-expected.txt
[delete] https://crrev.com/e6a59a6bf0c44a45fabe15389cd29373325eb4e8/third_party/WebKit/LayoutTests/external/wpt/wake-lock/interfaces.https-expected.txt
[delete] https://crrev.com/e6a59a6bf0c44a45fabe15389cd29373325eb4e8/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-api.https-expected.txt
[modify] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-api.https.html
[delete] https://crrev.com/e6a59a6bf0c44a45fabe15389cd29373325eb4e8/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-applicability-manual.https-expected.txt
[delete] https://crrev.com/e6a59a6bf0c44a45fabe15389cd29373325eb4e8/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-cancel-twice.https-expected.txt
[modify] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-disabled-by-feature-policy.https.sub-expected.txt
[delete] https://crrev.com/e6a59a6bf0c44a45fabe15389cd29373325eb4e8/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-document-hidden.https-expected.txt
[modify] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-enabled-by-feature-policy-attribute-redirect-on-load.https.sub-expected.txt
[delete] https://crrev.com/e6a59a6bf0c44a45fabe15389cd29373325eb4e8/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-enabled-by-feature-policy-attribute.https.sub-expected.txt
[delete] https://crrev.com/e6a59a6bf0c44a45fabe15389cd29373325eb4e8/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-enabled-by-feature-policy.https.sub-expected.txt
[modify] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-enabled-on-self-origin-by-feature-policy.https.sub-expected.txt
[delete] https://crrev.com/e6a59a6bf0c44a45fabe15389cd29373325eb4e8/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-onactivechange.https-expected.txt
[delete] https://crrev.com/e6a59a6bf0c44a45fabe15389cd29373325eb4e8/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-promise.https-expected.txt
[delete] https://crrev.com/e6a59a6bf0c44a45fabe15389cd29373325eb4e8/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-state-is-global.https-expected.txt
[modify] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-type.https-expected.txt
[modify] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-type.https.html
[delete] https://crrev.com/e6a59a6bf0c44a45fabe15389cd29373325eb4e8/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelockrequest-is-independent.https-expected.txt
[modify] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/blink/renderer/core/events/event_type_names.json5
[modify] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/blink/renderer/modules/event_target_modules_names.json5
[modify] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/blink/renderer/modules/modules_idl_files.gni
[modify] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/blink/renderer/modules/wake_lock/BUILD.gn
[modify] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/blink/renderer/modules/wake_lock/DEPS
[add] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/blink/renderer/modules/wake_lock/navigator_wake_lock.cc
[add] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/blink/renderer/modules/wake_lock/navigator_wake_lock.h
[add] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/blink/renderer/modules/wake_lock/navigator_wake_lock.idl
[add] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/blink/renderer/modules/wake_lock/wake_lock.cc
[add] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/blink/renderer/modules/wake_lock/wake_lock.h
[add] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/blink/renderer/modules/wake_lock/wake_lock.idl
[add] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/blink/renderer/modules/wake_lock/wake_lock_request.cc
[add] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/blink/renderer/modules/wake_lock/wake_lock_request.h
[add] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/blink/renderer/modules/wake_lock/wake_lock_request.idl
[modify] https://crrev.com/a4fd427d8a3b82bd55cd9d64c480d5d610d9c599/third_party/blink/renderer/platform/runtime_enabled_features.json5

Project Member

Comment 65 by bugdroid1@chromium.org, Oct 4

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/67d51b1fc81dc108bd4fe78a479f7dab6c8bdf1d

commit 67d51b1fc81dc108bd4fe78a479f7dab6c8bdf1d
Author: Mrunal Kapade <mrunal.kapade@intel.com>
Date: Thu Oct 04 21:23:55 2018

Wake Lock API: Add implementation for System wake lock

This patch enables system wake lock on blink side by making use of
ServiceManager Connector and WakeLockProvider.

BUG= 873030 ,257511

Change-Id: Ie4cb38124d0072d12d663ef4d1ae7311a1233460
Reviewed-on: https://chromium-review.googlesource.com/c/1256220
Commit-Queue: Mrunal Kapade <mrunal.kapade@intel.com>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596856}
[modify] https://crrev.com/67d51b1fc81dc108bd4fe78a479f7dab6c8bdf1d/content/public/app/mojo/content_renderer_manifest.json
[delete] https://crrev.com/aed2f80ffd9053837f90100cf999b64af72b90e4/third_party/WebKit/LayoutTests/external/wpt/wake-lock/wakelock-type.https-expected.txt
[modify] https://crrev.com/67d51b1fc81dc108bd4fe78a479f7dab6c8bdf1d/third_party/blink/renderer/modules/wake_lock/DEPS
[modify] https://crrev.com/67d51b1fc81dc108bd4fe78a479f7dab6c8bdf1d/third_party/blink/renderer/modules/wake_lock/navigator_wake_lock.cc
[modify] https://crrev.com/67d51b1fc81dc108bd4fe78a479f7dab6c8bdf1d/third_party/blink/renderer/modules/wake_lock/navigator_wake_lock.h
[modify] https://crrev.com/67d51b1fc81dc108bd4fe78a479f7dab6c8bdf1d/third_party/blink/renderer/modules/wake_lock/wake_lock.cc
[modify] https://crrev.com/67d51b1fc81dc108bd4fe78a479f7dab6c8bdf1d/third_party/blink/renderer/modules/wake_lock/wake_lock.h

Labels: -Pri-3 Proj-Fugu Pri-1
Labels: Target-None M-72
Blockedon: 903831
Cc: tsteiner@google.com
Project Member

Comment 70 by bugdroid1@chromium.org, Dec 12 (4 days ago)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2e5e1813e67fc6e07f7984f612ba99bffb240fb9

commit 2e5e1813e67fc6e07f7984f612ba99bffb240fb9
Author: Mrunal Kapade <mrunal.kapade@intel.com>
Date: Wed Dec 12 19:03:31 2018

Wake Lock API: Add checks for feature policy.

Added checks for feature policy attribute. This fixes all feature policy
related tests.

BUG= 862460 ,257511

Change-Id: I6258c41dcca164f7c6584ba4a387860237ca3ba3
Reviewed-on: https://chromium-review.googlesource.com/c/1343193
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Commit-Queue: Mrunal Kapade <mrunal.kapade@intel.com>
Cr-Commit-Position: refs/heads/master@{#615985}
[modify] https://crrev.com/2e5e1813e67fc6e07f7984f612ba99bffb240fb9/third_party/blink/common/feature_policy/feature_policy.cc
[modify] https://crrev.com/2e5e1813e67fc6e07f7984f612ba99bffb240fb9/third_party/blink/public/mojom/feature_policy/feature_policy.mojom
[modify] https://crrev.com/2e5e1813e67fc6e07f7984f612ba99bffb240fb9/third_party/blink/renderer/core/feature_policy/feature_policy.cc
[modify] https://crrev.com/2e5e1813e67fc6e07f7984f612ba99bffb240fb9/third_party/blink/renderer/modules/wake_lock/navigator_wake_lock.cc
[delete] https://crrev.com/631de05f60396066a876145334427efd257188b2/third_party/blink/web_tests/external/wpt/wake-lock/wakelock-disabled-by-feature-policy.https.sub-expected.txt
[delete] https://crrev.com/631de05f60396066a876145334427efd257188b2/third_party/blink/web_tests/external/wpt/wake-lock/wakelock-enabled-by-feature-policy-attribute-redirect-on-load.https.sub-expected.txt
[delete] https://crrev.com/631de05f60396066a876145334427efd257188b2/third_party/blink/web_tests/external/wpt/wake-lock/wakelock-enabled-on-self-origin-by-feature-policy.https.sub-expected.txt
[modify] https://crrev.com/2e5e1813e67fc6e07f7984f612ba99bffb240fb9/third_party/blink/web_tests/external/wpt/wake-lock/wakelock-enabled-on-self-origin-by-feature-policy.https.sub.html
[modify] https://crrev.com/2e5e1813e67fc6e07f7984f612ba99bffb240fb9/tools/metrics/histograms/enums.xml

Comment 71 by dxie@google.com, Dec 13 (4 days ago)

Labels: -M-72 -Target-None M-76 Target-73

Sign in to add a comment