Intent to Implement: User Idle Detection
Sam Goto
Contact emails
go...@chromium.org, jsb...@chromium.org, rei...@chromium.org
Explainer
Link to explainer and WICG thread.
Design doc/Spec
Not yet available. Will update this thread when ready. There is a Chrome Apps API and early prototype.
Summary
The User Idle Detection API gives developers the ability to be notified when users go idle (e.g. they don’t interact with the keyboard/mouse/screen, when a screensaver kicks in and/or when the screen gets locked) past a certain time limit , even beyond their content area (e.g. when users move to a different window/tab).
Motivation
Native applications / extensions (e.g. Chrome apps, Android apps, Firefox extensions, Edge extensions) use idle detection to notify other users (e.g. chat apps letting other users know that the user isn’t active), to show timely alerts (e.g. “welcome back” when a user goes idle and restarts their task) or to pause media (e.g. to save bandwidth when the user is idle).
Currently, web apps (e.g. Dropbox’s idle.ts) are constrained to (a) polling for input events (b) within their own content area and (c) are unable to tell the difference between an idle user and a user with a locked screen.
To satisfy these use cases there is a possible overlap with other noteworthy APIs which we’ll learn more about as we go and get more developer feedback:
The Page Visibility API fires events when the page isn’t visible anymore (e.g. the user tabs out or the screen goes off) but it doesn’t give an indication whether the user is idle or active elsewhere. Notably, it should probably fire an event when the screen gets locked too, which could be used to pause media.
The requestIdleCallback detects when the CPU is idle (as opposed to the user) and it is used to schedule work without causing UI jank.
The Wake Lock API gives you the ability to keep the screen on even as users go idle.
Risks
Interoperability and Compatibility
Edge: Shipped in extensions, no public comment on web facing API
Firefox: Shipped in extensions, no public comment on web facing API
Safari: No signals
Web / Framework developers: Dropbox polyfill, detecting idle
Ergonomics
> Are there any other platform APIs this feature will frequently be used in tandem with?
Nothing immediate comes to mind. Note that requestIdleCallback detects when the CPU is idle (rather than the user) to schedule work without causing UI jank, so, unrelated.
> Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?
Nothing immediately comes to mind that would be less performant/powerful than setTimeout.
Activation
> Will it be challenging for developers to take advantage of this feature immediately, as-is?
I don’t believe so. There aren’t any dependencies on other web features, nor a specific device.
> Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?
Existing JS libraries (e.g. Dropbox’s) could be turned into partial polyfills or be used as a distribution mechanism to increase activation.
Debuggability
Developers can manually debug/trigger this feature setting low thresholds (e.g. 10 seconds) of idleness which reproduces the feature consistently and quickly. Reproducing locking the screen is a bit more tricky, but still doable manually.
It would be helpful if devtools allowed simulating idle or screen lock on a mobile device, etc. It **can** be tested manually, but it is not as convenient (e.g. one has to wait X number of seconds, etc).
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes. There is currently implementation support in Chromium for detecting idle and screenlock states in Chrome OS, Linux, Windows and macOS. It is unclear what “idle” means for mobile devices (e.g. android phones) and this is one of the things we’ll be investigating. There is an analogy for “locking screen” and it is detectable on Android. It is unclear at the moment if the Android WebView has the mechanism to detect idleness/locking, needs further investigation.
Is this feature fully tested by web-platform-tests?
Tests will be added as WPT where possible.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/4590256452009984
Requesting approval to ship?
No