Quirks of the Page Visibility API
1–10 of 22 posts
Re: Quirks of the Page Visibility API
#2IIRC this comes down to disagreements between browser vendors as to what is and what isn't potentially harmful (for a wide definition of harmful) detection of user behavior.
I don't remember the details, but expect browsers to differ on details of this API basically forever.
Re: Quirks of the Page Visibility API
#3It might make sense to detect page visibility prior to loading a pay-per-load API like Mapbox GL JS, Apple Maps on Web, etc.
The scenario I imagine is:
1. Your map is loaded
2. User opens a new tab (your map is now in a background tab)
3. User restarts browser and existing tabs are loaded
4. You get charged for an API load even though the page is not visible
Does anyone know if this is the case?
Edit: also analytics. If you don't load your GA until page is visible, I wonder what impact that has on your visitor numbers
Re: Quirks of the Page Visibility API
#4There are still very few addons you can install on Firefox for Android (without a dev version and a bunch of hassle), but it's telling that one of the few addons that anyone can install disables this API: https://addons.mozilla.org/android/addon/video-background-pl...
Re: Quirks of the Page Visibility API
#5IIRC this comes down to disagreements between browser vendors as to what is and what isn't potentially harmful (for a wide definition of harmful) detection of user behavior. I don't remember the details, but expect browsers to differ on details of this API basically forever.
Why isn't the user in charge of whether they want the page visibility api to report them?
Re: Quirks of the Page Visibility API
#6IIRC this comes down to disagreements between browser vendors as to what is and what isn't potentially harmful (for a wide definition of harmful) detection of user behavior. I don't remember the details, but expect browsers to differ on details of this API basically forever.
Why isn't the user in charge of whether they want the page visibility api to report them?
How do you imagine the UI for managing that? Don't forget that there are a dozen other APIs with permissions as well.
Re: Quirks of the Page Visibility API
#7Earlier quoted context omitted.
Why isn't the user in charge of whether they want the page visibility api to report them?
How do you imagine the UI for managing that? Don't forget that there are a dozen other APIs with permissions as well.
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).
Re: Quirks of the Page Visibility API
#8Earlier quoted context omitted.
How do you imagine the UI for managing that? Don't forget that there are a dozen other APIs with permissions as well.
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).
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.
Re: Quirks of the Page Visibility API
#9Earlier quoted context omitted.
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).
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 sw…
> 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.
Re: Quirks of the Page Visibility API
#10Earlier quoted context omitted.
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 sw…
> 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…
> why not?
Because some of them are harmless, some of them are less harmless. Same goes for all the other APIs that require user permissions. In the end the user will just click "yes" on all of them.
> 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.
Does the user know what those checks are? Did you know which checks the visibility API does before reading the article? I sure as hell didn't.
> E.g., the visibilityChange event does not fire when user sets the toggle to true.
This has unintended consequences. For example, a well-meaning website performing intensive computation only when the page is visible.