Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wake lock: Adapt to the latest version of the spec (9a17e1f48) #16844

Merged
merged 1 commit into from May 24, 2019

Conversation

@chromium-wpt-export-bot
Copy link
Collaborator

chromium-wpt-export-bot commented May 15, 2019

This CL includes an implementation of the Wake Lock spec after
https://github.com/w3c/wake-lock/pull/201 and subsequent pull requests that
clear up a few points.

Specifically, this CL implements the Wake Lock spec at commit
9a17e1f48ca519090b82dddca09ace3e1773931c ('Explain why WakeLock.request()
has no "if aborted" step').

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/c/chromium/src/+/1605687
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#663207}

Copy link
Collaborator

wpt-pr-bot left a comment

Already reviewed downstream.

@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-1605687 branch 3 times, most recently from bd24c30 to 76590bc May 17, 2019
@chromium-wpt-export-bot chromium-wpt-export-bot changed the title [WIP] wake lock: Adapt to the version of the spec in PR #201 wake lock: Adapt to the latest version of the spec (9a17e1f48) May 23, 2019
@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-1605687 branch from 76590bc to 55cf7f2 May 23, 2019
This CL includes an implementation of the Wake Lock spec after
https://github.com/w3c/wake-lock/pull/201 and subsequent pull requests that
clear up a few points.

Specifically, this CL implements the Wake Lock spec at commit
9a17e1f48ca519090b82dddca09ace3e1773931c ('Explain why WakeLock.request()
has no "if aborted" step').

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/c/chromium/src/+/1605687
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#663207}
@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-1605687 branch from 55cf7f2 to 743317f May 24, 2019
@chromium-wpt-export-bot chromium-wpt-export-bot merged commit 512a587 into master May 24, 2019
11 checks passed
11 checks passed
manifest-build-and-tag manifest-build-and-tag
Details
staging.wpt.fyi - safari[experimental] Safari results
Details
website-build-and-publish website-build-and-publish
Details
wpt.fyi - safari[experimental] Safari results
Details
Azure Pipelines Build #20190524.99 succeeded
Details
Azure Pipelines (./wpt test-jobs) ./wpt test-jobs succeeded
Details
Azure Pipelines (affected tests (Safari Technology Preview)) affected tests (Safari Technology Preview) succeeded
Details
Azure Pipelines (affected tests without changes (Safari Technology Preview)) affected tests without changes (Safari Technology Preview) succeeded
Details
Azure Pipelines (wpt.fyi hook: safari-preview-affected-tests) wpt.fyi hook: safari-preview-affected-tests succeeded
Details
Azure Pipelines (wpt.fyi hook: safari-preview-affected-tests-without-changes) wpt.fyi hook: safari-preview-affected-tests-without-changes succeeded
Details
Taskcluster (pull_request) TaskGroup: success
Details
@chromium-wpt-export-bot chromium-wpt-export-bot deleted the chromium-export-cl-1605687 branch May 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.