3 ms·
Mind you, it's not just about the user explicitly inactivating the tab/window; the page visibility API also considers the page to be invisible if you completely
by derefr 4y ago
Mind you, it's not just about the user explicitly inactivating the tab/window; the page visibility API also considers the page to be invisible if you completely cover the viewport by moving another window in front of said page's viewport. Or, for that matter, if the viewport is owned by an iframe, and that iframe is scrolled out of the bounds of its parent viewport.
The intention behind the Page Visibility API is supposed to be to allow the page to stop bothering to run JS intended solely to calculate DOM updates, if said DOM isn't currently being rendered where the user can see it. Like how "damage region"-based redraw event-pumping worked in native apps before window managers started doing compositing; or how culling works in 3D rendering. The browser asks the OS to notify it whenever the tab's viewport is entirely occluded; and when the browser receives said notification, it translates that to a Page Visibility API event for the tab.
And the annoying thing about that, is that an opt-in in this case would do away with all the subtle improvements to battery life that are the "correct" use-case of this API. It'd be like having to explicitly prompt the user to opt-in to allowing the use of WEBMs for displaying animations on pages, while allowing actual .GIF-file animations all the time. Websites that are just websites, not long-use apps, would know that users don't care enough to take the time to understand what's being asked and opt in to using extra APIs with them, so 80% of the time they'd get refused; so, for a "clean experience", they just wouldn't bother to ask, and would instead just consider the API verboten, and stick with doing the worse, more-CPU-intensive thing.
Meanwhile, the malicious use-cases would just ask; because for the malicious use-case, even just those 20% of users who naively default to "yes" to prompts instead of "no" would be enough to ensure they siphon off enough data to sell for sweet, sweet ad-tech dollars. (At least, that's how things seem to be for the similar Background Notification API.)
Effectively, you'd punish honest use-cases of the API (because the devs were only doing it out of the goodness of their hearts, and so a little thing like "80% of users won't benefit" is enough to make those devs not bother), while not really thwarting malicious use-cases (because they're highly incentivized.)
- alwayslikethis 4y agoThat would be a loss for sure, but I think the dangers of surveillance far outweighs the reduced CPU load from not rendering content sometimes. Wouldn't it be better to have the browser do this instead, by somehow ignoring the rendering when the tab is not visible? As a side note, can you give a website where this is done? I feel like most modern websites are so bloated that no amount of these subtle optimizations would be better than just having a more minimalistic design, such as not fetching things continuously by default and doing away with unneeded animations.
- derefr 4y ago> Wouldn't it be better to have the browser do this instead, by somehow ignoring the rendering when the tab is not visible? The browser does already do this. Browsers are already smart enough to not "reflect" DOM updates to currently-hidden parts of the DOM into re-rendering passes. (Which is one reason a lot of people think "virtual DOM" frameworks are silly.) What the Page Visibility API allows you to save the expense of, is running the JavaScript logic that translate into those DOM update calls. (Think: the logic that decides what horrible banner ad to fetch next, actually pre-fetches it, and then updates the DOM to tell the browser it's the ad that should be being displayed. Disabling that logic when the banner ad isn't visible => no more background network fetches for new ads.) This requires an API, because the browser can't just be reaching into a Turing machine (i.e. some arbitrary Javascript program that could really be trying to do anything, given that webapps exist) and randomly shutting parts of it off. The browser needs a clear signal to hand that page-embedded Turing machine to say "if you have a part that's just for the sake of figuring out what to show next on the screen, then please stop running that part for now." That signal is a Page Visibility event. (Though, this isn't the only way to accomplish that. If said Javascript program has provided a clear rendering API to the browser, that works too! I.e., if the page is pumping its logic using Window.requestAnimationFrame, then IIRC the browser can take as long as it likes to call the requestAnimationFrame callback back — and if the window is occluded, that would be a perfect time for the browser to wait on that. But if you think about it, "requestAnimationFrame taking longer to get called back" exposes basically the same data-leak that the Page Visibility API does, so...) > As a side note, can you give a website where this is done? YouTube, I believe, has independent video and audio streams, precisely so that whenever you leave the viewport occluded for a few seconds, it can stop bothering to fetch the video stream (or can drop the video stream down to the lowest resolution+bitrate version), while continuing to play the previous highest-negotiated-bitrate audio stream.