Screen Wake Lock API
Categories
(Core :: DOM: Device Interfaces, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox122 | --- | fixed |
People
(Reporter: marcosc, Assigned: vhilla)
References
(Depends on 1 open bug, Blocks 2 open bugs, )
Details
(Keywords: dev-doc-complete)
Attachments
(8 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
Bug 1589554 - Part 4: Release/Deny screen-wake-lock for implementation-specific reasons. r=#dom-core
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
3.11 KB,
text/plain
|
cboozarjomehri
:
data-review+
|
Details |
The WakeLock API allows web applications to request a wake lock. A wake lock prevents some aspect of the device from entering a power-saving state (e.g., preventing the system from turning off the screen).
Spec:
https://w3c.github.io/wake-lock/
Non-video use cases are outlined here:
https://www.w3.org/TR/wake-lock-use-cases/
Comment 1•5 years ago
|
||
Gecko still have old (B2G eara) XPCOM APIs for wake lock and devtools may use it.
Reporter | ||
Comment 2•5 years ago
|
||
Great! Yes, I saw there was already HAL infrastructure in place. We don't have any plans to actually implement this. I've requested a standards position on it. At least we have have a record if we decide to proceed or not. Setting to P5 till we work out what we want to do.
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Updated•4 years ago
|
Comment 3•4 years ago
|
||
Mozilla landed on "worth prototyping" as the official position.
https://mozilla.github.io/standards-positions/#screen-wake-lock
Updated•4 years ago
|
Updated•2 years ago
|
Can you reconsider the priority and severity? Chrome has implemented it and soon Safari too: https://github.com/WebKit/WebKit/pulls?q=Screen+Wake+Lock
The workaround with nosleep.js is rather costly (code overhead+dependency, battery?) and from my experience is not 100% really reliable.
Comment 5•1 year ago
|
||
I'm also interested to hear if there is any interest in prioritising this. MDN now lists all browsers as having full support for this except for Firefox and Firefox Mobile: https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake_Lock_API#browser_compatibility
Comment 6•11 months ago
|
||
Just a heads up: Chrome has changed the rules around when the wake lock automatically gets held/activated (see https://bugs.chromium.org/p/chromium/issues/detail?id=1446737) lots of video calling services are forced to implement support for actively requesting the wake lock via this API. This will result in the screen lock behavior to be the same across all browsers for each of these services, except on Firefox.
Which isn't a problem as long as the screen saver doesn't kick in on Firefox. But once it does the service will most likely recommend their users to simply switch to any of the browsers which support the wake lock API, and avoid trying to write special code for Firefox.
Thus I would recommend someone from Mozilla to look into shipping this, especially since to me this doesn't look like a very complex feature.
Updated•11 months ago
|
Comment 7•11 months ago
•
|
||
Jib, could you take a look at this proposal? Wondering if we have an updated position on it. Doubt this falls under media or webrtc so we might have to promote it within another team if we think it's worth implementing.
Updated•11 months ago
|
Comment 8•11 months ago
|
||
This isn't media related, media grabs a wake lock implicitly most of the time. The DOM team is taking a look.
Media is a primary user of the platform code we have to implement this, however, but exposing the API to the Web isn't related to media.
Updated•11 months ago
|
Assignee | ||
Updated•9 months ago
|
Assignee | ||
Comment 9•7 months ago
|
||
Assignee | ||
Comment 10•7 months ago
|
||
Depends on D189508
Assignee | ||
Comment 11•7 months ago
|
||
Depends on D189509
Assignee | ||
Comment 12•7 months ago
|
||
Depends on D189510
Assignee | ||
Comment 13•7 months ago
|
||
Depends on D189511
Assignee | ||
Comment 14•7 months ago
|
||
Depends on D189512
Assignee | ||
Comment 15•7 months ago
|
||
Depends on D189513
Updated•7 months ago
|
Updated•7 months ago
|
Updated•7 months ago
|
Updated•7 months ago
|
Updated•7 months ago
|
Updated•7 months ago
|
Updated•7 months ago
|
Updated•7 months ago
|
Updated•7 months ago
|
Assignee | ||
Comment 16•5 months ago
|
||
Comment 17•5 months ago
|
||
Comment on attachment 9364743 [details]
request.md
Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?
Yes.
Is there a control mechanism that allows the user to turn the data collection on and off?
Yes. This collection can be controlled through the product's preferences.
If the request is for permanent data collection, is there someone who will monitor the data over time?
Yes, Vincent Hilla is responsible.
Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?
Category 2, Interaction.
Is the data collection request for default-on or default-off?
Default on for all channels.
Does the instrumentation include the addition of any new identifiers?
No.
Is the data collection covered by the existing Firefox privacy notice?
Yes.
Does the data collection use a third-party collection tool?
No.
Result: datareview+
Comment 18•5 months ago
|
||
Pushed by vhilla@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b55991835aec Part 1: Screen Wake Lock boilerplate. r=dom-core,smaug,emilio,edgar https://hg.mozilla.org/integration/autoland/rev/82e03a404c2f Part 2: Implement Screen Wake Lock API. r=dom-core,edgar https://hg.mozilla.org/integration/autoland/rev/202c4f5c642b Part 3: Screen Wake Lock permission integration. r=webidl,dom-core,smaug,pbz,edgar https://hg.mozilla.org/integration/autoland/rev/e02e11c3d977 Part 4: Release/Deny screen-wake-lock for implementation-specific reasons. r=dom-core,edgar https://hg.mozilla.org/integration/autoland/rev/f1500173aa53 Part 5: Screen Wake Lock telemetry. r=dom-core,edgar https://hg.mozilla.org/integration/autoland/rev/76a3c248813f Part 6: Screen Wake Lock testing. r=webdriver-reviewers,webidl,dom-core,saschanaz,whimboo,edgar https://hg.mozilla.org/integration/autoland/rev/a0db8be67659 Part 7: Add logging to Screen Wake Lock. r=dom-core,edgar
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/43519 for changes under testing/web-platform/tests
Comment 20•5 months ago
|
||
Backed out for causing non-unified bustages on WakeLockJS.cpp.
Failure log: https://treeherder.mozilla.org/logviewer?job_id=438909392&repo=autoland
Backout link: https://hg.mozilla.org/integration/autoland/rev/f1977b0c7b96ec566139fbccda3083c211bfd2ab
Upstream PR was closed without merging
Comment 22•5 months ago
|
||
Pushed by vhilla@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f50ff29a1a64 Part 1: Screen Wake Lock boilerplate. r=dom-core,smaug,emilio,edgar https://hg.mozilla.org/integration/autoland/rev/231b0b4efd16 Part 2: Implement Screen Wake Lock API. r=dom-core,edgar https://hg.mozilla.org/integration/autoland/rev/f932a2a98670 Part 3: Screen Wake Lock permission integration. r=webidl,dom-core,smaug,pbz,edgar https://hg.mozilla.org/integration/autoland/rev/4880b1f5b3bc Part 4: Release/Deny screen-wake-lock for implementation-specific reasons. r=dom-core,edgar https://hg.mozilla.org/integration/autoland/rev/c8908ceacbe2 Part 5: Screen Wake Lock telemetry. r=dom-core,edgar https://hg.mozilla.org/integration/autoland/rev/4c6403ab4174 Part 6: Screen Wake Lock testing. r=webdriver-reviewers,webidl,dom-core,saschanaz,whimboo,edgar https://hg.mozilla.org/integration/autoland/rev/f3c72b5730df Part 7: Add logging to Screen Wake Lock. r=dom-core,edgar
Comment 23•5 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/f50ff29a1a64
https://hg.mozilla.org/mozilla-central/rev/231b0b4efd16
https://hg.mozilla.org/mozilla-central/rev/f932a2a98670
https://hg.mozilla.org/mozilla-central/rev/4880b1f5b3bc
https://hg.mozilla.org/mozilla-central/rev/c8908ceacbe2
https://hg.mozilla.org/mozilla-central/rev/4c6403ab4174
https://hg.mozilla.org/mozilla-central/rev/f3c72b5730df
Upstream PR was closed without merging
Upstream PR merged by moz-wptsync-bot
Assignee | ||
Updated•5 months ago
|
Assignee | ||
Comment 26•5 months ago
|
||
The backout was due to lacking #include "mozilla/StaticPrefs_dom.h"
Comment 27•5 months ago
|
||
:vhilla/:edgar could you consider nominating this for a release note? (Process info)
Comment 28•5 months ago
|
||
(nominating this for a Nightly release note)
Release Note Request (optional, but appreciated)
[Why is this notable]: New web API (navigator.wakeLock)
[Affects Firefox for Android]: Yes
[Suggested wording]: Added support for Screen Wake Lock API.
[Links (documentation, blog post, etc)]: https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake_Lock_API
Comment 29•5 months ago
|
||
Thanks, added to the Fx122 nightly release notes, please allow 30 minutes for the site to update.
Keeping the relnote-firefox flag as ? to keep it on the radar for inclusion in the final Fx122 release notes
Comment 30•4 months ago
|
||
Set the release note flag to nightly+, this is only enabled in nightly builds.
https://searchfox.org/mozilla-central/source/modules/libpref/init/StaticPrefList.yaml#3473
Comment 31•4 months ago
|
||
FF122 MDN docs work for this tracked in https://github.com/mdn/content/issues/31112
Comment 32•2 months ago
|
||
This was added to the final Fx124 relnotes in bug 1874849.
Description
•