1241309 - <video>.play() doesn't kick off playback

Status: RESOLVED WORKSFORME

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

Description

[David Walsh :davidwalsh]

When testing potential partner apps for Firefox OS for TV, we've encountered many apps that were made for Google TV and thus uses Google's "gtv" JavaScript helper.  Sites using this helper work properly in Chrome but Firefox has a problem with <video>.play() whereby the play() method is called but the video doesn't play.

The problem doesn't just occur in Firefox OS but also in desktop Firefox.  A few sample URLs where you can view the problem:

http://www.funnyordie.com/googletv/fullscreen.html?category=0&item=1
http://www.ign.com/videos/tv/

When exploring and using Charles Proxy to debug the videocontrol.js file provided by gtv (http://www.funnyordie.com/googletv/js/videocontrol.js), I've found that adding a `setTimeout` with `0` delay around the `video.play()` call in `gtv.jq.VideoControl.prototype.playPause` allows the video to play properly:

```
video.play(); // Doesn't play
setTimeout(function() { video.play(); }, 0); // Plays
```


To that end I believe this is a platform issue. I'm happy to provide more specific information when requested.

Marking as confidential since we use potential partner URLs.  Marking as major as this is a major stumbling block in acquiring content for Firefox OS for TV.

Comment 2

[:Harald Kirschner :digitarald]

Making bug public as URLs are public.

Comment 3

[Michael Ellis]

Adding Josh, Joe, & Evelyn to this bug.  Setting NI on Evelyn

Comment 4

[Evelyn Hung]

To clarify the problem, here is my observation:

I tried the two links on my Firefox desktop browser and Chrome browser, the only difference I noticed is: it starts playing *automatically* after page/media loaded on Chrome, but not on Firefox. You need an extra click on the content to play.

and your finding is: wrapping the play() in a setTimeout can workaround this issue.

Isn't it?

It sounds to me a timing issue, I'm not sure if there is a bug in our platform. It may possibly because we the media content haven't been completely loaded and we try to call the play(), so it failed. (and somehow Chrome loaded the content faster or it reports status before content loaded)

It's common to use setTimeout(..., 0) to make sure the operation happening in the next tick (by pushing it to the end of event queue), so it might not be a bug. I'm not sure.

Comment 5

[David Walsh :davidwalsh]

Correct: simply adding a setTimeout of 0 around the play() call makes autoplay work properly.

Is there someone we can include from platform on this to weigh in?  As I said, this is a big hurdle for getting content for Firefox OS TV.  The user experience of autoplay vs. having to navigate buttons to play is a huge gap.

Comment 6

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

According to bug description, this also happen on desktop browser. Correct the Product/Component field. @jya might have some idea about this issue.

Comment 7

[JW Wang [:jwwang] [:jw_wang]]

I saw the error: JavaScript error: http://www.funnyordie.com/googletv/js/videocontrol.js, line 439: TypeError: Not enough arguments to TimeRanges.end. which might be the reason to prevent videocontrol.js from working properly.

Also, if you right click and select "Play", the playback will start correctly. I think the problem is in videocontrol.js instead of the media element.

Comment 8

[David Walsh :davidwalsh]

I added try/catch around the calls you're talking about causing errors and it had no affect.

Comment 9

[JW Wang [:jwwang] [:jw_wang]]

Did you click on the video or the icon below to start playback?

Comment 10

[David Walsh :davidwalsh]

I did, and it worked, but that's not relevant; autoplay is meant to begin.

Comment 11

[JW Wang [:jwwang] [:jw_wang]]

The correct way is to add 'autoplay' to the video tag. Don't call play() in the script to simulate 'autoplay'.

Comment 12

[David Walsh :davidwalsh]

Adding an `autoplay` attribute instead of calling `play()` on a `video` at any desired time seems nonsensical.  `video.play()` should kick off loading and playing of a video when directed, no?

Comment 13

[JW Wang [:jwwang] [:jw_wang]]

It should. But it is tricky that the video has 2 source children.

<source src="http://hls.fod4.com/master/v/811563fd03/v600,v400,v200,v110,v1200/master.m3u8">
<source src="http://vo.fod4.com/v/811563fd03/v2500.mp4">

The 1st one will cause load error and reset the media element to 'paused' before trying to load the next child. Therefore, you have to call play() again as soon as it begins to load the 2nd child.

'autoplay' will save the headache for you when it comes to multiple <source>s and you don't know which child will be loaded successfully.

Comment 14

[David Walsh :davidwalsh]

Interesting....Chrome must either support the first source or moves on to the second in the case of a fail.  Thank you for the insight!

Comment 15

[Jean-Yves Avenard [:jya]]

(In reply to JW Wang [:jwwang] from comment #13)
> It should. But it is tricky that the video has 2 source children.
> 
> <source
> src="http://hls.fod4.com/master/v/811563fd03/v600,v400,v200,v110,v1200/
> master.m3u8">
> <source src="http://vo.fod4.com/v/811563fd03/v2500.mp4">
> 
> The 1st one will cause load error and reset the media element to 'paused'
> before trying to load the next child. Therefore, you have to call play()
> again as soon as it begins to load the 2nd child.

Maybe it shouldn't fall back to paused.
Don't see why it should.

In any case, our fallback support is pretty poor. Only if the format isn't supported will we fallback to the next source.
If the first src is invalid or can't be decoded, we won't.

Comment 16

[Jean-Yves Avenard [:jya]]

(In reply to David Walsh :davidwalsh from comment #14)
> Interesting....Chrome must either support the first source or moves on to
> the second in the case of a fail.  Thank you for the insight!

it's the 2nd. Chrome doesn't support HTTP Live Streaming either.

Comment 17

[JW Wang [:jwwang] [:jw_wang]]

(In reply to Jean-Yves Avenard [:jya] from comment #15)
> Maybe it shouldn't fall back to paused.
> Don't see why it should.


https://dev.w3.org/html5/spec-preview/media-elements.html#loading-the-media-resource
4.6 If the paused attribute is false, then set it to true.

Comment 18

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Mass change P2 -> P3

Comment 19

[Timea Cernea [:tbabos][inactive]]

Closing this as resolved:worksforme. The first example link requires a password to view the content and the second link from IGN will play the video without the need for any additional clicks on the latest Firefox Nightly 96.0a1 on MacOS 10.15.
If this issue is still reproducible for you, please do re-open it and let us know. Thanks.