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

Idle Detection API should allow for limiting to an origin #36

Closed
tomayac opened this issue Feb 3, 2021 · 4 comments
Closed

Idle Detection API should allow for limiting to an origin #36

tomayac opened this issue Feb 3, 2021 · 4 comments

Comments

@tomayac
Copy link
Contributor

tomayac commented Feb 3, 2021

"[The Idle Detection API] should support customizing the detection scheme. It should also allow to just specify "detect if user has the tab focused, and is interacting with the document". In that scenario it shouldn't prompt (there's no privacy concern because you can already implement that on your own). It should definitely keep prompting for what it does right now: detecting idle state across tabs & OS apps — not only that, it should explicitly say in the prompt that it'll do this (which I didn't know about when I read it at first)."—via @dwelle on excalidraw/excalidraw#2877 (comment) in excalidraw/excalidraw#2877.

This could look like the following snippet and would only cover tabs opened to the mentioned origin and thus not report on activity in other non-browser apps or non-related tabs, and likewise allow for no assumptions about the screenState—and due to its reduced powers not require permissions, since the same can be implemented client-side today.

const controller = new AbortController();
const signal = controller.signal;
const idleDetector = new IdleDetector();
idleDetector.start({
  threshold: 60_000,
  signal: signal,
  origin: 'example.com', // 🆕
});
@reillyeon
Copy link
Collaborator

Since sites can polyfill this behavior is it worth adding complexity to the API to support this?

@tomayac
Copy link
Contributor Author

tomayac commented Feb 10, 2021

Counter argument: jQuery was a "polyfill" to what became Web platform APIs. Since polyfilling this feature typically involves setting up many listeners, it can be easy to shoot oneself in the foot when one forgets to remove them. If done at the browser level, there is also potential for a more performant or less taxing implementation.

@dwelle
Copy link

dwelle commented Feb 10, 2021

I believe it's much better if the work is done right once by the browsers, rather than [potentially] suboptimally (as @tomayac pointed out) thousands (or more) of times over by people who want this behavior. And since Idle Detection API now exists, it's a perfect fit to implement this browser-side.

@tomayac
Copy link
Contributor Author

tomayac commented Oct 27, 2021

In the Devices and Sensors WG meeting at TPAC the following was decided:

  • tomayac: is there a plan to have this limited to an origin?
    … I implemented this for a popular PWA and they do not need all the features of the API, only for their own origin
  • reillyg: my feeling is that since this can be polyfilled, it doesn't seem worthwhile to increase the complexity of the API

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants