Intent to Continue Experimenting: Idle Detection API

[Reilly Grant]

Contact emails

ay...@chromium.org, rei...@chromium.org

Explainer

https://github.com/WICG/idle-detection/blob/master/README.md

Specification

https://wicg.github.io/idle-detection

API spec

Yes

Documentation

https://web.dev/idle-detection/
https://github.com/WICG/idle-detection/blob/main/mdn-drafts/QUICK-REFERENCE.md

Summary

The Idle Detection API notifies developers when a user is idle, indicating such things as lack of interaction with the keyboard, mouse, screen, activation of a screensaver, locking of the screen, or moving to a different screen. A developer-defined threshold triggers the notification.

Blink component

Blink>Input

TAG review

https://github.com/w3ctag/design-reviews/issues/336

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

The IdleDetector interface complements existing indicators of user activity such as mouse and keyboard events, and the page visibility state. Sites using an IdleDetector should function correctly in browsers which do not implement it (as they do today) but with all the known problems documented in the motivations for introducing this API.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/453)

WebKit: Negative (https://lists.webkit.org/pipermail/webkit-dev/2020-October/031565.html)

Web developers: Positive (https://discourse.wicg.io/t/idle-detection-api/2959)

Ergonomics

This API uses asynchronous events and Promise-returning functions to allow Chrome to maintain good performance and future-proof the design.

Activation

https://github.com/dropbox/idle.ts provides a polyfill for a version of this API which only uses input events that are available to the page. The benefit of this API comes from the (limited) information it provides about user input events that are not available to the page. It is possible that this polyfill could be updated to use this API to provide a more complete picture of user presence and activity. Developer outreach has already begun, including a post about the feature on web.dev.

Security

The security and privacy risks are discussed in the explainer and draft specification.

Goals for experimentation

The goal of this experiment is to validate that the API provides an improved user experience. Interested developers have been able to build prototypes while this feature has been available behind a flag. The purpose of the trial is to determine whether using this API provides a measurably better user experience.

Experimental timeline

The experiment will be extended for 3 additional milestones, continuing through the stable release of Chrome 91 and ending a week before the stable release of Chrome 94.

Reason this experiment is being extended

Our web developer partner was unable to launch an experiment using this API immediately after the release of Chrome 88 to stable channel. That experiment is now running and requires the API to be available for a few more milestones in order to produce useful data.

Ongoing technical constraints

None.

Debuggability

An option to override the Idle Detection state for testing purposes is available through Chrome DevTools in the Sensors panel.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No, this feature is supported on all platforms other than Android WebView. Adding support for this final platform requires plumbing a new permission type through the WebView API.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

IdleDetection

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=878979

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1129665

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/4590256452009984

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msg/blink-dev/OuwzBmH02M4/5ChXdXZQBwAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/9OwINXHzbUE/m/LOcbtEjAAAAJ
Intent to Continue Experimenting: https://groups.google.com/a/chromium.org/g/blink-dev/c/tkdwZYCI4EE/m/L6-Gw2-kCAAJ

This intent message was generated by Chrome Platform Status.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

[Yoav Weiss]

So the API was OTed M84-M89. This intent will run it again M91-M94.

The 1 milestone break in the API's availability assures me there's no premature reliance on the API's availability, so we can safely continue experimenting with it.

LGTM to experiment M91-M94. 

On Tuesday, May 4, 2021 at 2:11:10 AM UTC+2 Reilly Grant wrote:

Contact emails

ay...@chromium.org, reillyg@chromium.org

Something broken about the latest link here. I think it should be this one. 

[Reilly Grant]

On Wed, May 5, 2021 at 6:02 AM Yoav Weiss <yoav...@chromium.org> wrote:

So the API was OTed M84-M89. This intent will run it again M91-M94.

The 1 milestone break in the API's availability assures me there's no premature reliance on the API's availability, so we can safely continue experimenting with it.

The original OT ran M84-86, we skipped M87 and then restarted it in M88-90. This extension will extend it through M93, but since our partner only started rolling out their experiment after the M90 stable release effectively it will only be in use from M90-93. I've taken a look at the signups and metrics for this trial and usage is very low, mostly just people testing on localhost. There is no current risk of burn-in.

 

LGTM to experiment M91-M94. 

On Tuesday, May 4, 2021 at 2:11:10 AM UTC+2 Reilly Grant wrote:

Contact emails

ay...@chromium.org, rei...@chromium.org

[Yoav Weiss]

Thanks for the correction. Still LGTM.