Closed Bug 1589554 Opened 5 years ago Closed 6 months ago

Screen Wake Lock API

Categories

(Core :: DOM: Device Interfaces, enhancement)

enhancement

Tracking

()

RESOLVED FIXED
122 Branch
Tracking Status
firefox122 --- fixed

People

(Reporter: marcosc, Assigned: vhilla)

References

(Blocks 2 open bugs, )

Details

(Keywords: dev-doc-complete)

Attachments

(8 files)

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/

Gecko still have old (B2G eara) XPCOM APIs for wake lock and devtools may use it.

Depends on: 1054113

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.

Type: defect → enhancement
Priority: -- → P5
Blocks: 1054113
No longer depends on: 1054113
Summary: Wake Lock API → Screen Wake Lock API

Mozilla landed on "worth prototyping" as the official position.

https://mozilla.github.io/standards-positions/#screen-wake-lock

Blocks: wakelock
Severity: normal → S3

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.

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

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.

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.

Flags: needinfo?(jib)
Severity: S3 → --
Priority: P5 → --

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.

Flags: needinfo?(jib)
No longer blocks: media-triage
Assignee: nobody → vhilla
Depends on: 1524074
Attachment #9355595 - Attachment description: Bug 1589554 - Part 1: Screen Wake Lock boilerplate. → WIP: Bug 1589554 - Part 1: Screen Wake Lock boilerplate.
Attachment #9355596 - Attachment description: Bug 1589554 - Part 2: Implement Screen Wake Lock API. → WIP: Bug 1589554 - Part 2: Implement Screen Wake Lock API.
Attachment #9355595 - Attachment description: WIP: Bug 1589554 - Part 1: Screen Wake Lock boilerplate. → Bug 1589554 - Part 1: Screen Wake Lock boilerplate. r=#dom-core
Attachment #9355596 - Attachment description: WIP: Bug 1589554 - Part 2: Implement Screen Wake Lock API. → Bug 1589554 - Part 2: Implement Screen Wake Lock API. r=#dom-core
Attachment #9355597 - Attachment description: Bug 1589554 - Part 3: Screen Wake Lock permission integration. → Bug 1589554 - Part 3: Screen Wake Lock permission integration. r=#dom-core
Attachment #9355598 - Attachment description: Bug 1589554 - Part 4: Release/Deny screen-wake-lock for implementation-specific reasons. → Bug 1589554 - Part 4: Release/Deny screen-wake-lock for implementation-specific reasons. r=#dom-core
Attachment #9355599 - Attachment description: Bug 1589554 - Part 5: Screen Wake Lock telemetry. → Bug 1589554 - Part 5: Screen Wake Lock telemetry. r=#dom-core
Attachment #9355600 - Attachment description: Bug 1589554 - Part 6: Screen Wake Lock testing. → Bug 1589554 - Part 6: Screen Wake Lock testing. r=#dom-core
Attachment #9355601 - Attachment description: Bug 1589554 - Part 7: Add logging to Screen Wake Lock. → Bug 1589554 - Part 7: Add logging to Screen Wake Lock. r=#dom-core
Attached file request.md
Attachment #9364743 - Flags: data-review?(royang)

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+

Attachment #9364743 - Flags: data-review?(royang) → data-review+
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
Upstream PR was closed without merging
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
Upstream PR was closed without merging
Upstream PR merged by moz-wptsync-bot
Regressions: 1868562
Flags: needinfo?(vhilla)

The backout was due to lacking #include "mozilla/StaticPrefs_dom.h"

Regressions: 1869118

:vhilla/:edgar could you consider nominating this for a release note? (Process info)

Flags: needinfo?(vhilla)
Flags: needinfo?(echen)

(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

relnote-firefox: --- → ?
Flags: needinfo?(vhilla)
Flags: needinfo?(echen)

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

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

FF122 MDN docs work for this tracked in https://github.com/mdn/content/issues/31112

Blocks: 1874849
Blocks: 1877413

This was added to the final Fx124 relnotes in bug 1874849.

Regressions: 1881070
See Also: → 1883724
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: