Track native window occlusion state and use it to save resources (was: Document visibility is not hidden when an application is overlayed on top of a browser tab)
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
People
(Reporter: wessel_kroos, Unassigned)
Details
(Keywords: power)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36
Steps to reproduce:
Operating System: Windows 10 (64-bits)
What steps will reproduce the problem?
(1) Go to https://codepen.io/wesselkroos/pen/rNywpKQ
(This page plays a video, watches document visibilitychanges and schedules animationFrame callbacks)
(2) Start an application (for example: File Explorer) and overlay it on top of the codepen browser tab
(3) Tab back to the codepen website
This is a common usecase for users that play a game or use an application while:
- Listening to a video in the background
- Listening to audio in the background
- Still have a tab open in the background on a website with running animations
Fixing this will spare CPU and GPU usage that could be fully utilized by the game or application in focus.
Actual results:
When an application overlays on top of a tab so that it obscures it completely:
- document.visibilityState is still "visible" and thus does not trigger the visibilitychange event handler
- The browser keeps firing requestAnimationFrame callbacks
- The browser keeps drawing video frames (See the GPU usage of Firefox in the Windows Task Manager)
Expected results:
When an application overlays on top of a tab so that it obscures it completely:
- document.visibilityState will be set to "hidden" and trigger the visibilitychange event handler
- The browser stops firing requestAnimationFrame callbacks
- The browser stops drawing video frames
This already works when you tab to another browser tab.
Comment 1•3 years ago
|
||
I can reproduce this issue in Windows 10, Mac OS 11.3.1 and Fedora 33 with all the latest versions of the main channels.
If the user opens the testpage in comment 0, and then overlaps the browser with any other app, the codepen will not detect the fact that it lost focus and became "invisible" (not in view). Furthermore, when the user minimizes the browser and then maximizes back into view, he will notice that the events between "hidden" and "visible" events are still being incorrectly triggered.
These issues do not occur in the Chrome browser.
Comment 3•3 years ago
|
||
IIRC this only works as comment 0 describes on Chrome on Windows (and maybe ChromeOS per the docs?). It certainly doesn't seem to work on Chrome on Linux.
I think this is sort of an enhancement request, but would be nice to do. One of the things we should test for when implementing this is all these Citrix-like enterprise environments, because Chrome got it wrong and got a massive media backlash in this bug.
Updated•3 years ago
|
Comment 4•3 years ago
|
||
Emilio,
Sotaro has started working on window occlusion for Win32 over in bug 1688997. It seems like it might be a dupe of the work described here, but I wanted to point you at it. Can you take a look and see if that bug is covering everything here? You might also mention the Citrix use-case you talk about in comment 3. Thanks.
Comment 5•3 years ago
|
||
Yeah, it's a dupe. Great we're working on this.
Updated•3 years ago
|
Description
•