1736448 - Change of virtual desktop doesn't emit an event with Page Visibility API

Status: NEW

(Core :: Widget: Win32, enhancement, P5)

Description

[Louis Poirier]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

Create a simple HTML page.
Add Javascript and listen to "visibilitychange" document's event :

document.addEventListener("visibilitychange", () => {
console.log("onVisibilityChanged");
if (document.hidden) console.log("hidden");
else console.log("visible");
});

Open this HTML document in Firefox from a virtual desktop A.
Switch to a virtual desktop B.
Come back to virtual desktop A.

Actual results:

Nothing happened. No event emitted.

Expected results:

Expect event to be emitted.

When switching tabs or reducing / maximizing window, event is emitted and values updated.

It should behave the same with virtual desktop's navigation.

Comment 1

[Pablo]

thanks for opening this enhancement, i will set it as new so the devs can take a look at it

Comment 2

[Stephen A Pohl [:spohl]]

Can you provide some background/documentation why you believe that this should be the case? The windows continue to be "visible" on the virtual desktop. Just because you switch from one virtual desktop to another doesn't really affect the visibility of individual windows on one virtual desktop or another. The reason why they're not displayed on your screen would be because you switched between virtual desktops, not because the windows became invisible.

Comment 3

[Louis Poirier]

Thank you for your reply.
I understand your point. However I believe it to be an issue from the point of view of a user.

When switching of tab / reducing a window, it is no longer visible to the user. Current implementation does emit events in order to listen to this change.
When switching of virtual desktop, it is also no longer visible to the user. But current implementation doesn't emit events.
In this regard, I believe current implementation to be incoherent.

Emitting such events with this API allows:

• to stop / pause a process (video / audio / game), to reduce power consumption and CPU overload.
• moreover, it allows to implement features to improve user's experience.

Current W3C document on Page Visibility says in 1. Introduction:

[...] Designing web pages with knowledge of the document's visibility state can result in improved user experiences and power efficient sites.

As an example, I'm implementing a 3D game as a web application. If a player switch to another virtual desktop for any reason, it is better to know this change of state so that I can pause the game.

In this same document at section 3. Visibility states:

The steps to determine the visibility state of a browsing context context are as follows. The steps return a visibility state.

1. Let doc be the context's top-level browsing context's active document.
2. Assert: doc is a Document.
3. Return visible if:

• The user agent has assistive technologies attached to the doc.
• Any of the doc's viewport contents are visible to the user.

4. Otherwise, return hidden.

Visibility of document's viewport is defined from the point of view of the user.

Back to my example, when player switch to another virtual desktop, game loop / GPU / CPU are still running:

• when player get back to the game, he's character might just be dead because while absent, AI kept "playing".
• it wastes resources / battery.
• and player would not be happy to start over.

This example is for local only, but it would have even more impact with multiplayer content.

This feature is already present on Edge and Chrome. While I'm not saying Firefox must copy them by the book, I believe it was implemented for good reasons, and that such implementation in Firefox would benefit everyone.

Comment 4

[Stephen A Pohl [:spohl]]

My understanding of a virtual desktop aligns with the idea of a "separate" desktop, just that it happens to be virtual. In other words, conceptually, the issue at hand here would be the same if you had a separate desktop machine running the game/website, but you turn off the monitor. Or you turn your back to the desktop machine running the game, and you're now looking at a monitor of a second desktop machine. It is interesting to hear that Edge and Chrome do not handle this situation this way.

Emilio, do you have any thoughts here? Or would you know who to ask for guidance?

Comment 5

[Emilio Cobos Álvarez (:emilio)]

If the window is hidden by a virtual desktop we should arguably be marking the document as hidden, yeah. Sotaro, I wonder if the Windows occlusion work that you've been doing fixes this (on Windows at least)?

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Test-case for convenience.

FWIW on Linux Chrome behaves the same as Firefox (doesn't fire events either)

Comment 7

[Louis Poirier]

Thank you for your feedback both.

Emilio, I've just test it again, on Windows with Chrome, it does fire events. Maybe results are different due to underlying OS implementation of virtual desktop... or it is just not present on Linux version of Chrome for now.

Comment 8

[Sotaro Ikeda [:sotaro]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

If the window is hidden by a virtual desktop we should arguably be marking the document as hidden, yeah. Sotaro, I wonder if the Windows occlusion work that you've been doing fixes this (on Windows at least)?

I confirmed that with Bug 1732737, event was fired on Windows.