There 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...
IIRC 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.
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.
> 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.
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.
> 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.
An inscrutable power-user feature to appease some privacy purist nerds, all while the 99.999% leaves it set to the default behaviour and gets screwed by ad companies. That’s not fighting for privacy, it’s copping out.
Seems like a good use case. I wrote a Christmas quiz app in December and I could see from the server logs someone must have left the scoreboard page open for weeks as I used polling to check for the latest score. Checking if the tab was even active would have been a good idea.
I tried using the page visibility API to refresh displayed data when the user returned to the page after being away for a while. It's more efficient than needlessly polling when no one's around to see.
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.
Off topic: This page is yet another example of many, many websites that display a useless horizontal scrollbar. Non-overlay scrollbars simply do not work with elements that are set to a width of 100vw. Using 100vw is almost always a mistake.
Hi there, thanks for the feedback! I overlooked testing with scrollbars set to always show, as Firefox recently started following macOS/Windows system settings rather than using its own setting. I've updated the CSS to use `100%` to rectify this. For this specific post, a bare link was also causing additional horizontal scroll, so I addressed both in https://github.com/devadvance/devadvance.github.io/commit/6a....
