YouTube plugin does not work on iOS. No play button appears.

[joelransom]

When I first started using Popcorn i had no problem using the YouTube player on iOS. The user had to press play, but otherwise everything worked.

Now, the play button does not even appear. The Popcorn.js fiddle for demonstrating the youtube player exhibits this behavior: http://jsfiddle.net/popcornjs/whvkP/

Just want to clarify if this is a bug or expected behavior/limitation.

Thanks.

[ScottDowne]

It is not intended. How long ago was this breakage? Days or months?

I'm on Android atm and while it plays for me the experience is pretty choppy. The video itself has a hard time playing.

We have not changed much as far as I know on our end so I fear something may of changed in ios youtube or flash. More detective work is required.

[joelransom]

It has been this way over a month. I put a question about it on SO in May but got no bites. So I'd say it was working 2 months ago.

At the time of the SO post I also said "The video will start to load, you can see the title, but then instead of a prominent "Play" button you get a black screen with a miniscule white dot in the center. If you press that barely visible dot the video will play and the popcorn code will execute fine."I don't seem to be able to start it at all now, perhaps that is intermittent.

I don't believe I've updated my popcorn.js libraries, so I tend to agree that something may have changed on their end. I'm running 1.3 if that helps any.

Thanks,

Joel

[mindmelting]

I am also seeing this behaviour...

[ckng]

Using 1.4, Youtube player not working under iOS Chrome/Safari.

So are Popcorn Youtube and Popcorn 101.

[ScottDowne]

I'm going to look into this.

It seems the YouTube API auto plays on first interaction, like a seek. So if the first thing the player does is a seek, it is going to autoplay. It also doesn't start to load until the play. The YouTube wrapper popcorn uses tries to be HTML5 like as much as it can, so this autoplay "feature" needs to be triggered and done with in order to get to that HTML5 feel.

Autoplay on first seek filed with YouTube for more info: http://code.google.com/p/gdata-issues/issues/detail?id=2916&can=1&q=reporter%3Ascott.downe%40gmail.com&colspec=API%20ID%20Type%20Status%20Priority%20Stars%20Summary

This autoplay is removed using a play/pause call before we fire the ready event. That play/pause is not going to work on mobile, it has to be a user interacted play, and not an API play.

It is still doable, and we probably need to make a special case for iOs.

Oddly enough, works in FF mobile on android.

Also, I keep fighting with issues like this and YouTube. It keeps coming back to the fact that YouTube is optimized for straight, user interacted playthrough, not API calls. The API is secondary.

The above ticket is a good example of this. Playing on first seek makes a lot of sense for UI/UX point of view. If a user clicks seek on the YouTube player they likely want to play shortly after. However, that kind of feature should be moved into the controls play button, and not the API itself. The play button should and can handle this, and the API should do exactly what I asked it to do, and no more. You can see their point of view, but you can also see how they don't get the API point of view by their comment in the ticket. "I don't understand the use case for needing to call seekTo() on an unstarted player" UI and API is the same thing to them.

So, if we need to hit play before we're ready, but we need to be ready before we hit play, we have the bug above.

I'm fairly sure this can be fixed, just saying why it does what it does, by looking at the code. A fix would need to consider desktop too, and work around this somehow.

I would rather not have to wait for interaction before loading by default on desktop, it already takes long enough.

Whew, sorry for the wall of text, but it's a complex problem.

Filed it here: https://bugzilla.mozilla.org/show_bug.cgi?id=920103

On 24 September 2013 11:51, CK Ng notifications@github.com wrote:

Using 1.4, Youtube player not working under iOS Chrome/Safari.

So are Popcorn Youtube http://popcornjs.org/popcorn-with-youtube and Popcorn 101 http://popcornjs.org/popcorn-101.

— Reply to this email directly or view it on GitHubhttps://github.com/mozilla/popcorn-js/issues/320#issuecomment-25017187 .

[joelransom]

Thanks for the update Scott. If I can help in any way let me know. 

— Sent from Mailbox for iPhone

On Tue, Sep 24, 2013 at 9:41 AM, ScottDowne notifications@github.com wrote:

I'm going to look into this. It seems the YouTube API auto plays on first interaction, like a seek. So if the first thing the player does is a seek, it is going to autoplay. It also doesn't start to load until the play. The YouTube wrapper popcorn uses tries to be HTML5 like as much as it can, so this autoplay "feature" needs to be triggered and done with in order to get to that HTML5 feel. Autoplay on first seek filed with YouTube for more info: http://code.google.com/p/gdata-issues/issues/detail?id=2916&can=1&q=reporter%3Ascott.downe%40gmail.com&colspec=API%20ID%20Type%20Status%20Priority%20Stars%20Summary This autoplay is removed using a play/pause call before we fire the ready event. That play/pause is not going to work on mobile, it has to be a user interacted play, and not an API play. It is still doable, and we probably need to make a special case for iOs. Oddly enough, works in FF mobile on android. Also, I keep fighting with issues like this and YouTube. It keeps coming back to the fact that YouTube is optimized for straight, user interacted playthrough, not API calls. The API is secondary. The above ticket is a good example of this. Playing on first seek makes a lot of sense for UI/UX point of view. If a user clicks seek on the YouTube player they likely want to play shortly after. However, that kind of feature should be moved into the controls play button, and not the API itself. The play button should and can handle this, and the API should do exactly what I asked it to do, and no more. You can see their point of view, but you can also see how they don't get the API point of view by their comment in the ticket. "I don't understand the use case for needing to call seekTo() on an unstarted player" UI and API is the same thing to them. So, if we need to hit play before we're ready, but we need to be ready before we hit play, we have the bug above. I'm fairly sure this can be fixed, just saying why it does what it does, by looking at the code. A fix would need to consider desktop too, and work around this somehow. I would rather not have to wait for interaction before loading by default on desktop, it already takes long enough. Whew, sorry for the wall of text, but it's a complex problem. Filed it here: https://bugzilla.mozilla.org/show_bug.cgi?id=920103 On 24 September 2013 11:51, CK Ng notifications@github.com wrote:

Using 1.4, Youtube player not working under iOS Chrome/Safari.

So are Popcorn Youtube http://popcornjs.org/popcorn-with-youtube and Popcorn 101 http://popcornjs.org/popcorn-101.

— Reply to this email directly or view it on GitHubhttps://github.com/mozilla/popcorn-js/issues/320#issuecomment-25017187 .

---

Reply to this email directly or view it on GitHub: https://github.com/mozilla/popcorn-js/issues/320#issuecomment-25021094

[wsl]

It's indeed the autoplay which breaks it on ipad.

In the

/popcorn-js/wrappers/youtube/popcorn.HTMLYouTubeVideoElement.js

in the onPlayerReady function (around line 108) some tricks are done for autoseek & mute for initial loading. The player.playVideo(); in that function breaks it for the iPad because the youtube API does not allow autoplay on iPad. It should always start with a user interaction

If you comment the player.playVideo(); line it works (for me).

http://stackoverflow.com/questions/16661217/popcorn-js-on-mobile-browser-youtube-play-button-does-not-appear

[ScottDowne]

The only thing it is going to break is preload and autoplay. Some desktop apps require this.

I wonder if we can just turn off that initial play by setting up a preload=none, and from there force preload to be none on a mobile app. It won't fix iphone but it'll fix ipad.

On 20 December 2013 20:54, Wessel notifications@github.com wrote:

It's indeed the autoplay which breaks it on ipad.

In the

/popcorn-js/wrappers/youtube/popcorn.HTMLYouTubeVideoElement.js

in the onPlayerReady function (around line 108) some tricks are done for autoseek & mute for initial loading. The player.playVideo(); in that function breaks it for the iPad because the youtube API does not allow autoplay on iPad. It should always start with a user interaction

If you comment the player.playVideo(); line it works (for me).

http://stackoverflow.com/questions/16661217/popcorn-js-on-mobile-browser-youtube-play-button-does-not-appear

— Reply to this email directly or view it on GitHubhttps://github.com/mozilla/popcorn-js/issues/320#issuecomment-31054108 .

[wsl]

Removing this player.playVideo(); also breaks the play() function (because the mediaReady is not set because the preload is not done). So should only be done when autoplay is not possible.

I'm looking into: http://stackoverflow.com/a/17836886/273143 for feature detection of the autoplay function. Or you do think iOS detection sufficient?

This http://stackoverflow.com/q/7120703/273143 also describes a nice hack in the first update: create a small initialization video with just a play button and if that has been started iOS seems to accept that as enabling the youtube API.

This last trick is usable for me but I can imagine it's too specific for popcornjs.

[ScottDowne]

Hm, maybe we leave the feature detection or browser detection up to the code controlling popcorn, and just have that be passed to the youtube wrapper? So, have the code controlling popcorn figure it out, and then enable or disable autoplay via some sort of config?

On 2 January 2014 16:32, Wessel Louwris notifications@github.com wrote:

Removing this player.playVideo(); also breaks the play() function (because the mediaReady is not set because the preload is not done). So should only be done when autoplay is not possible.

I'm looking into: http://stackoverflow.com/a/17836886/273143 for feature detection of the autoplay function. Or you do think iOS detection sufficient?

This http://stackoverflow.com/q/7120703/273143 also describes a nice hack in the first update: create a small initialization video with just a play button and if that has been started iOS seems to accept that as enabling the youtube API.

This last trick is usable for me but I can imagine it's too specific for popcornjs.

— Reply to this email directly or view it on GitHubhttps://github.com/mozilla/popcorn-js/issues/320#issuecomment-31486510 .

[xangadix]

for completeness I would add: if ( navigator.userAgent.toLowerCase().indexOf("ipad") == -1 ) player.playVideo()

With a code comment, and/or a link to this thread, this fixes the bug for 99% of the users, and instructs any developer on the how and why of this addition.

I've just tested it again and behaviour on ipad is now in agreement with Apple TOS. Apple won't allow preloading or autoplay of video, now a user has to click to 'enable' the video, and then the popcorn wrapper takes over. That is to say, for any video without autoplay, the user has to click again on play. This may seem weird from a usability standpoint, but is exactly how it should be according to apple tos.

[jtomaszewski]

Seems like we have to forget about .play() method when running play for the first time - user has to click on the youtube's applet on its' own to make it play.

Also, we've got an autoplay bug here: this line forces the youtube video to be autoplayed, so instead of seeing youtube's image with 'play icon', we'll just see a dark background (thus, the user has no idea that he should click on it to make it play).

My solution:

• comment this line with if (!navigator.userAgent.match(/(iPad|iPhone|iPod)/g)) conditional
• force the user to actually click the 'youtube' applet to make it play

Propably i'll have to do the same workarounds in other wrappers (f.e. soundcloud).

[xangadix]

Hey Jacek,

Couldn't agree more, in my own fork I've forced this behavior on all players to keep it consistent for my clients, haven't had a complaint about it since. Also, make sure to hide any and all custom controls you might have. I've noticed that my users tend to press the play button under the video first, not noticing the big red youtube play button. So now I fade in the controls after the youtube video is 'activated' and actually works. ( top of my head; that is the "videoloaded" callback )

cheers. Daan

On Sat, Apr 18, 2015 at 1:37 PM, Jacek Tomaszewski <notifications@github.com

wrote:

Seems like we have to forget about .play() method when running play for the first time - user has to click on the youtube's applet on its' own to make it play.

Also, we've got an autoplay bug here: this line https://github.com/mozilla/popcorn-js/blob/master/wrappers/youtube/popcorn.HTMLYouTubeVideoElement.js#L122 forces the youtube video to be autoplayed, so instead of seeing youtube's image with 'play icon', we'll just see a dark background (thus, the user has no idea that he should click on it to make it play).

My solution:

• comment this line https://github.com/mozilla/popcorn-js/blob/master/wrappers/youtube/popcorn.HTMLYouTubeVideoElement.js#L122 with if (!navigator.userAgent.match(/(iPad|iPhone|iPod)/g)) conditional
• force the user to actually click the 'youtube' applet to make it play

— Reply to this email directly or view it on GitHub https://github.com/mozilla/popcorn-js/issues/320#issuecomment-94158879.

[jtomaszewski]

I noticed the same problem appears on Android 5 (Lollipop)... anybode else encountered it too? I had to to changed my regexpes to if (!navigator.userAgent.match(/(iPad|iPhone|iPod|Android 5)/g)) , to fix it.

[jtomaszewski]

I've fixed it in youtube & soundcloud elements in https://github.com/jtomaszewski/popcorn-js/commit/37604f93ff7210992f8b9e513f36abc63a580672 . Propably similar fix is needed for other elements, like vimeo for example.

It works correctly right now. Remeber to set popcorn.autoplay = false;.

Tests are missing unfortunately atm. Maybe someone wants to create a pull request , also with tests?