Open Bug 1742465 Opened 3 years ago Updated 3 years ago

Autoplay blocking blocks player on lfm.ch, even if initiated by the user (Android)

Categories

(Core :: Audio/Video: Playback, defect)

defect

Tracking

()

People

(Reporter: amejia, Unassigned)

Details

Attachments

(1 file)

Steps to reproduce

  1. Open https://www.lfm.ch/player/popup/index.html
  2. Click the play icon

Expected behavior

Stream starts.

Actual behavior

Stream does not start. Instead, you'll see a autoplay blocking message in the console:

Autoplay is only allowed when approved by the user, the site is activated by the user, or media is muted.

Even though the user just clicked on the play button. The site is probably doing some fancy JS magic to play the video and we don't realize the play was started by a DOM event, but maybe this is fixable.

Device information

  • Android device: (emulator)
  • Fenix version: Nightly 201104 17:01 (Build #2015773709)

Related ticket https://github.com/mozilla-mobile/fenix/issues/16402

Weird that it works on desktop via click (or after pausing, then playing again). Do we have a different policy on android vs. desktop or is something else going on?

Maybe the site behavior is different for small screens and could be causing issues with the auto play heuristics.

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

Weird that it works on desktop via click (or after pausing, then playing again). Do we have a different policy on android vs. desktop or is something else going on?

We do follow a slightly different code path on Android: https://searchfox.org/mozilla-central/rev/55a826a9ef74e92988e56cd9615d4fc6a470695e/dom/media/autoplay/AutoplayPolicy.cpp#194

After clicking on the page, media should suppose to be allowed due to the user gesture activation.

11-23 19:37:05.874 31679 31711 I Gecko : [Child 31679: Main Thread]: D/Autoplay Use 'sticky-activation', isAllowed=0

This is the first time media requested for play, but it seems we haven't received the gesture yet.

11-23 19:37:05.884 31679 31711 I Gecko : [Child 31679: Main Thread]: D/Autoplay Allow autoplay as top-level context has been activated by user gesture.

In this line, we can see gesture activation got updated correctly. So it seems to me that sticky gesture should be updated first, before sending the event to JS's event handler, in order to better handle the autoplay policy. So maybe the current process of updating the sticky activation is too late?

(In reply to Alastor Wu [:alwu] from comment #4)

So it seems to me that sticky gesture should be updated first, before sending the event to JS's event handler, in order to better handle the autoplay policy.

We do update the sticky gesture before we run the event handler (in EventStateManager::PreHandleEvent). Do you know where is the play request from, in a click event handler or something else?

From the log, it only showed that Load() is called from an event handler (see handlingInput) (which is called eariler than Play())

11-23 19:37:05.874 31679 31711 I Gecko   : [Child 31679: Main Thread]: D/Autoplay Use 'sticky-activation', isAllowed=0
11-23 19:37:05.874 31679 31711 I Gecko   : [Child 31679: Main Thread]: D/Autoplay IsAllowedToPlay, mediaElement=6f18916f00, isAllowToPlay=blocked
11-23 19:37:05.874 31679 31711 I Gecko   : [Child 31679: Main Thread]: D/nsMediaElement 6f18916f00 Load() hasSrcAttrStream=0 hasSrcAttr=1 hasSourceChildren=0 handlingInput=1 hasAutoplayAttr=0 IsAllowedToPlay=0 ownerDoc=6f111d3d00 (https://www.lfm.ch^privateBrowsingId=1) ownerDocUserActivated=0 muted=0 volume=1.000000

But at the time the Load() was being called, the autoplay is already blocked (the first and second line were called inside Load(), which means the check happened inside an event handler) If we did update the sticky gesture before the event handler, then the possible failed places are here where we couldn't get correct inner window, or document, but I don't know if that is possible? Or fail to get the top level window context so that we couldn't check the updated sticky gesture correctly?

Severity: -- → S4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: