Closed Bug 1553431 Opened 5 years ago Closed 5 years ago

[wpt-sync] Sync PR 16844 - [WIP] wake lock: Adapt to the version of the spec in PR #201

Categories

(Testing :: web-platform-tests, defect, P4)

defect

Tracking

(firefox69 fixed)

RESOLVED FIXED
mozilla69
Tracking Status
firefox69 --- fixed

People

(Reporter: mozilla.org, Unassigned)

References

()

Details

(Whiteboard: [wptsync upstream error])

Sync web-platform-tests PR 16844 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/16844
Details from upstream follow.

Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> wrote:

[WIP] wake lock: Adapt to the version of the spec in PR #201

This CL includes an implementation of the Wake Lock spec after
https://github.com/w3c/wake-lock/pull/201 [this will be updated once pending
clean-up PRs are merged too].

The spec has undergone significant changes since the latest update to the
implementation, and multiple features were added and removed to the spec in
the meantime.

From a Web API user perspective, the Wake Lock API surface is now pretty
small:

  • While the Wake Lock interface still exists, it only contains two static
    methods, requestPermission() and request(). requestPermission() needs
    pending work on the permissions side in //content and //chrome, so this CL
    only implements request().
  • navigator.getWakeLock() and WakeLock.createRequest() have been removed and
    replaced by a single call to WakeLock.request().
  • A consequence of the two items above is that it is no longer possible to
    actually hold a WakeLock object (and all attributes and event listeners
    are gone).
  • WakeLock.request() returns a promise that never resolves when it works,
    and rejects with either NotAllowedError or AbortError in case something
    did not work or the lock was cancelled.
  • We now use the AbortSignal mechanism from the DOM spec (just like other
    specs such as Fetch) for cancelling a Wake Lock.

From a Blink perspective:

  • wake_lock.cc just performs the validation steps in WakeLock.request(), and
    delegates the act of acquiring or releasing a wake lock to
    WakeLockController.
  • WakeLockController is similar to other controllers (like the ones in
    device_orientation/) and tracks per-Document wake lock state. It also does
    not acquire or release wake locks itself, but rather delegates it to its
    per-wake-lock-type instances of WakeLockStateRecord. It also handles
    per-document visibility and activity changes.
  • WakeLockStateRecord implements the spec's concept of "state record" and
    actually requests and cancels wake locks (by talking to //content and
    //services).

Major pending Wake Lock features present in the spec:

  • Workers support
  • Permission handling

Bug: 257511
Change-Id: I3dced3a16711b720a96b1a0d5c008d49e3b38c6d
Reviewed-on: https://chromium-review.googlesource.com/1605687
WPT-Export-Revision: 0b189376cba318d8ee2749315a0f56f0033147ac

PR 16844 applied with additional changes from upstream: 1701ea616b3289a31ff120bd3d54762e9cb62572, 91f7965fe94e30cb3437f4a21e9cb28485b195ae, bc3ffe739b2585189ed094ab2bac317724ed937a
Failed to get results from try push
Whiteboard: [wptsync downstream] → [wptsync downstream error]
Whiteboard: [wptsync downstream error] → [wptsync downstream]
Whiteboard: [wptsync downstream] → [wptsync downstream error]
Whiteboard: [wptsync downstream error] → [wptsync downstream]
Whiteboard: [wptsync downstream] → [wptsync downstream error]
Pushed by james@hoppipolla.co.uk:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c4d300356464
[wpt PR 16844] - wake lock: Adapt to the latest version of the spec (9a17e1f48), a=testonly
https://hg.mozilla.org/integration/mozilla-inbound/rev/2f51a285333c
[wpt PR 16844] - Update wpt metadata, a=testonly
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
Whiteboard: [wptsync downstream error] → [wptsync upstream error]
You need to log in before you can comment on or make changes to this bug.