Quirks of the Page Visibility API(mattj.io) |
Quirks of the Page Visibility API(mattj.io) |
I don't remember the details, but expect browsers to differ on details of this API basically forever.
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
I discovered a bunch of these edge cases and had to abandon the approach - it just wasn't reliable. The page would fail to recognize departure + return in too many scenarios and so wouldn't refresh.
- 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.
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.
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.
if the user wants the computation to continue, despite being not visible, the site should not be able to override it. It would be anti-user otherwise.
often, i would see video sites _not_ prebuffering when the page is not visible. Or, deliberately switch over to a low resolution version of the video when the visibility changes - twitch does that. Even if i have the video overlay playing outside the browser window (so technically, it is visible, just not according to the API).
Essentially, if the user has the know how to switch this preference (and it would be per site, or even per session, like mic or camera), they would know the consequences.
> require user permissions.
It's not a permission per se, but a toggle, so the user might turn it on or off depending on their circumstances. They don't need to understand it - they can just leave it on default as what the browser currently does if they don't understand, or don't have any problems with the site's behaviour.