Page Visibility API

Introduction

Sometimes, developers need to know that the user is leaving the page. The commonly used method is to monitor the following three events.

  • pagehide
  • beforeunload
  • unload

However, these events may not be triggered on the phone, and the page will simply be closed. Because the mobile phone system can directly transfer a process to the background and then kill it.

  • The user clicked on a system notification and switched to another App.
  • The user enters the task switching window and switches to another App.
  • The user clicks the Home button to switch back to the home screen.
  • The operating system automatically switches to another App (for example, a call is received).

The above situations will cause the mobile phone to switch the browser process to the background, and then in order to save resources, it may kill the browser process.

In the past, the page was switched by the system and the system cleared the browser process, which could not be monitored. Developers want to specify that any code that will be executed when the page is unloaded is also impossible to do. To solve this problem, the Page Visibility API was born. Regardless of mobile phone or desktop computer, in all cases, this API will monitor the visibility of the page to change.

The significance of this new API is that by monitoring the visibility of the webpage, it can predict the uninstallation of the webpage, and it can also be used to save resources and reduce power consumption. For example, once the user does not watch the webpage, the following webpage behaviors can be suspended.

  • Polling to the server
  • Web Animation
  • The audio or video being played

document.visibilityState

This API mainly adds a document.visibilityState property to the document object. This attribute returns a string that represents the current visibility state of the page. There are three possible values.

  • hidden: The page is completely invisible.
  • visible: At least part of the page is visible.
  • prerender: The page is about to be rendered or is being rendered and is in an invisible state.

Among them, the hidden state and the visible state must be supported by all browsers. The prerender state will only appear on browsers that support "pre-rendering". For example, the Chrome browser has a pre-rendering function, which can render the page in advance when the user wants to browse it. , Directly display the rendered web page.

As long as the page is visible, even if only one corner is exposed, the document.visibilityState property returns visible. Only the following four situations will return hidden.

  • The browser is minimized.
  • The browser is not minimized, but the current page is switched to the background page.
  • The browser is about to unload the page.
  • The operating system triggers the lock screen.

As you can see, the above four scenarios cover all situations where the page may be uninstalled. In other words, before the page is unloaded, the document.visibilityState property must become hidden. In fact, this is also the main purpose of designing this API.

In addition, in the earlier version of the API, this attribute has a fourth value unloaded, indicating that the page is about to be unloaded, which is now obsolete.

Note that the document.visibilityState property is only for the top-level window, and the document.visibilityState property of the embedded <iframe> page is determined by the top-level window. Using CSS properties to hide the <iframe> page (such as display: none;) will not affect the visibility of the embedded page.

document.hidden

For historical reasons, this API also defines the document.hidden property. This property is read-only and returns a Boolean value indicating whether the current page is visible.

When the document.visibilityState property returns visible, the document.hidden property returns false; otherwise, it returns true.

This property is only reserved for historical reasons. Whenever possible, the document.visibilityState property should be used instead of this property.

visibilitychange event

Whenever the document.visibilityState property changes, the visibilitychange event will be triggered. Therefore, you can track changes in page visibility by listening to this event (via the document.addEventListener() method or the document.onvisibilitychange property).

document.addEventListener("visibilitychange", function () {
  // The user left the current page
  if (document.visibilityState === "hidden") {
    document.title = "The page is not visible";
  }

  // The user opens or returns to the page
  if (document.visibilityState === "visible") {
    document.title = "Page is visible";
  }
});

The above code is the most basic usage of Page Visibility API, you can monitor visibility changes.

Here is another example, once the page is not visible, the video playback is paused.

var vidElem = document.getElementById("video-demo");
document.addEventListener("visibilitychange", startStopVideo);

function startStopVideo() {
  if (document.visibilityState === "hidden") {
    vidElem.pause();
  } else if (document.visibilityState === "visible") {
    vidElem.play();
  }
}

Page uninstall

Let's specifically discuss how to monitor page uninstallation correctly.

Page unloading can be divided into three situations.

  • When the page is visible, the user closes the Tab page or browser window.
  • When the page is visible, the user goes to another page in the current window.
  • When the page is not visible, the user or the system closes the browser window.

In these three cases, the visibilitychange event will be triggered. In the first two cases, the event is triggered when the user leaves the page; in the last case, the event is triggered when the page changes from a visible state to an invisible state.

It can be seen that the visibilitychange event is more reliable than the pagehide, beforeunload, and unload events, and will be triggered in all cases (from visible to hidden). Therefore, you can only monitor this event and run the code that needs to be run when the page is unloaded, instead of monitoring the next three events.

It can even be said that the unload event does not need to be monitored under any circumstances. The beforeunload event has only one applicable scenario, that is, the user modifies the form and leaves the current page without submitting it. On the other hand, if the listener function for these two events is specified, the browser will not cache the current page.