Autoplay blocking blocks player on lfm.ch, even if initiated by the user (Android)
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
People
(Reporter: amejia, Unassigned)
Details
Attachments
(1 file)
12.62 KB,
text/plain
|
Details |
Steps to reproduce
- Open https://www.lfm.ch/player/popup/index.html
- 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
Comment 1•3 years ago
|
||
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?
Reporter | ||
Comment 2•3 years ago
|
||
Maybe the site behavior is different for small screens and could be causing issues with the auto play heuristics.
Comment 3•3 years ago
|
||
(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
Comment 4•3 years ago
|
||
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?
Comment 5•3 years ago
|
||
(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?
Comment 6•3 years ago
•
|
||
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?
Updated•3 years ago
|
Description
•