undefined | Better HN

0 pointsdmitriid3y ago0 comments

How do you imagine the UI for managing that? Don't forget that there are a dozen other APIs with permissions as well.

0 comments

chii3y ago

I would imagine the UI to be similar to permission for microphone or camera. There's a default, and a per-site that a user can just override to disable visibility api checks (aka, a page would always think it is visible if set by the user).

dmitriidOP3y ago

But then there are multiple details in what activity the visibility API may expose. From the article:

- Browser window minimized

- browser window covered by another window that is larger

- tab hidden in an active browser window

- docking/undocking a tab to a browser window

- switched to a different desktop

- Browser window covered by another browser window that is the same size or smaller

- show desktop via F11 or swipe on touchpad

- opening Launchpad

- opening Mission Control

- dragging the window in Mission Control

- browser dialogs (print, save, etc.)

- during animation to/from full screen

- ...

The blanket "yes/no" setting isn't nearly enough for these kinds of things. And, again, there are dozens of APIs that require user permission in one way or another.

chii3y ago

> The blanket "yes/no" setting isn't nearly enough for these kinds of things.

why not?

These are all things the current underlying implementation checks for, and report via the visibility api, which is just a boolean effectively.

The user should be able to set a toggle, where the visibility api will return "true" (aka visible), for all of these underlying checks that the browser does. E.g., the visibilityChange event does not fire when user sets the toggle to true.

1 more reply

j / k navigate · click thread line to collapse

0 comments

chii3y ago

dmitriidOP3y ago

But then there are multiple details in what activity the visibility API may expose. From the article:

- Browser window minimized

- browser window covered by another window that is larger

- tab hidden in an active browser window

- docking/undocking a tab to a browser window

- switched to a different desktop

- Browser window covered by another browser window that is the same size or smaller

- show desktop via F11 or swipe on touchpad

- opening Launchpad

- opening Mission Control

- dragging the window in Mission Control

- browser dialogs (print, save, etc.)

- during animation to/from full screen

- ...

The blanket "yes/no" setting isn't nearly enough for these kinds of things. And, again, there are dozens of APIs that require user permission in one way or another.

chii3y ago

> The blanket "yes/no" setting isn't nearly enough for these kinds of things.

why not?

These are all things the current underlying implementation checks for, and report via the visibility api, which is just a boolean effectively.

1 more reply

j / k navigate · click thread line to collapse