plyr: YouTube autoplay broken in >= 3.3.8

Expected behaviour

Plyr should autoplay when the correct options are passed to the constructor.

Actual behaviour

Video loads, but doesn’t autoplay.

Steps to reproduce

Using the Codepen template, pass autoplay=true, muted=true, and volume=0 (links below)

Environment

  • Browser: Chrome 69, Firefox 62
  • Operating System: MacOS
  • Version: 10.13.6

Console errors (if any)

Link to where the bug is happening

Not working: https://codepen.io/anon/pen/KxZOqM (latest) Not working: https://codepen.io/anon/pen/GXyVmL (v 3.3.8) Working: https://codepen.io/anon/pen/aaEeWE (v 3.3.7)

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 13
  • Comments: 32 (5 by maintainers)

Commits related to this issue

Most upvoted comments

Your rude and ignorant comments makes it clear that you don’t know how browsers deal with auto play then, in addition to not knowing how human beings communicate or how free software works.

@turshija The only workaround I can think of (and using right now) is using the .play method.

player.on('ready', () => {
  player.play();
})

After reading out the code this plugin actually deletes the iframe and creates it again when you change the “sources” property to point to a different youtube video… which is incredibly stupid because it could just use the youtube API that is already using to change the video ID, so of course is not gonna auto-play because youtube considers this a “new” player created when the tab is out of focus. I saw the plugin looking so professional just to stumble upon this clusterfuck.

Given it’s so “incredibly stupid”, feel free to use your obviously superior intellect to put some effort in and open a PR to fix it? I really apologise for the “clusterfuck”. For free software that must have been terrible for you to experience but thanks for the kind words.

After reading out the code this plugin actually deletes the iframe and creates it again when you change the “sources” property to point to a different youtube video… which is incredibly stupid because it could just use the youtube API that is already using to change the video ID, so of course is not gonna auto-play because youtube considers this a “new” player created when the tab is out of focus. I saw the plugin looking so professional just to stumble upon this clusterfuck.

@friday The proper solution would be to have a player for each source (one for youtube, one for vimeo, etc) and hide them as needed, so that if the user is play-listing HTML5 videos only or Youtube videos only (the 2 most common playlisting use cases by far) neither need to be destroyed (or created more than once), this is specially critical on low-end mobile devices where too many DOM changes can make the device unresponsive.

HTML5 works: https://codepen.io/anon/pen/gZKZbo, so anyone who finds this issue critical can self-host the video (or try to fix the issue).

Not going to get a ton of upvotes for this comment I suspect 😃

That’s a terrible solution performance wise. Loading the different players and SDKs when not needed would be much worse performance. This is why the trend is to lazy load players. You’re also the first person to bring this up by the way. Your use-case isn’t everyone’s use-case. I am well aware there’s improvements to be made but you have to remember this is an open source project and 99% of the time it’s just me doing the bulk of the work and have to prioritize what gets done.

Google Chrome uses an ‘smart’ system to decide if a domain is allowed auto-play or not (at chrome://media-engagement/) which works fine and has nothing to do with the issue at hand, which is that youtube doesn’t let background tabs to autoplay on newly created players, which is necessary for any sort of playlist music players.

Google Chrome is not the only browser out there. Just for reference.

I’m not gonna do a PR

I was expecting a reply like that. 👍

This should be resolved. In my testing I found it was being paused right away on autoplay. I added a check for the autoplay and it seemed to fix it… https://github.com/sampotts/plyr/commit/2eccf0dd05f1678749a2c10c84e5c2bff03f1435#commitcomment-33155584

Let me know if there’s any issues 👍

@dacostafilipe, thanks for sharing your forks.

I created two new codepens from modifying the (latest) codepen in the op. fix-yt-autoplay: https://codepen.io/tttmack123/pen/WmMqzJ fix-yt-autoplay-v2: https://codepen.io/tttmack123/pen/moXZBR

For Windows, both of these autoplay on Chrome, FireFox, Edge and Opera. MacOS was not tested. Android 7.1.1 (Chrome) and iOS 12.1.4 (Chrome and Safari): neither of these autoplay (but neither did v3.3.7 codepen in the OP)

Additionally, the display of the controls in fix-yt-autoplay-v2 have some issues. When it doesn’t autoplay (iOS and Android), the button control bar is missing and the large play button is overlapped with the large built in YouTube play button. fix-yt-autoplay did not have this problem with displaying the controls. See these screenshots to compare the ways the controls are displayed on my iPad: https://imgur.com/a/AfgXPVF

Just tested it on chrome and it works.

Will do more testing on multiple browsers and create a PR for you.

Just had a look at the seeking code in youtube.js

At line L231 you define paused as true. So, in L393 you will always pause the video.

Even in the case where autoplay was added to the youtube iframe, you will still pause.

We could change L231 to something like:

player.media.paused = !player.config.autoplay;