Handling autoplay restrictions

Problem description

To avoid disturbing users, browsers restrict the autoplay of audio and video. A webpage with audio media elements is blocked from autoplaying until a user interacts with the page, such as by clicking or touching it (Autoplay policy in Chrome, Autoplay policy in Safari). Video-only playback is usually not restricted. However, in some scenarios, video-only autoplay is also restricted. Examples include iOS Safari in Low Power Mode and a restricted iOS WKWebView, such as the in-app browser of WeChat for iOS.

If this policy affects your application, calling the `play` method for an audio or video track in the DingRTC Web SDK before user interaction may result in no sound or video.

Solutions

• Listen for the "autoplay-failed" event. When media playback fails, prompt the user to interact with the page to resume playback.

  // The callback parameter is the audio or video track that failed to autoplay.
  DingRTC.on('autoplay-failed', (track) => {
    Modal.centerConfirm({
      content: 'Due to browser autoplay restrictions, click OK to start playing audio.',
      onOk: () => {
        track.play();
      },
    });
  });
  

• Prompt the user to interact with the page by clicking or touching it. Then, call the `play` method for an audio or video track.

  Most browsers lift the autoplay restriction after a user interacts with the page. However, policies are implemented differently by each vendor. Autoplay may still fail even after a user has interacted with the page. For example, this can happen in the in-app browser of WeChat for iOS and its Mini Program's WebView. In this scenario, add a prompt for the user to click or touch the page. Then, play the audio or video track in the callback for the click or touch event.