Vimeo controls displaying behing Plyr controls

[lukeyouell]

Issue is visible on plyr.io website (https://plyr.io/#vimeo)

Expected behaviour

Plyr controls should only be visible

Actual behaviour

Both Vimeo and Plyr controls are visible

Environment

• Browser: Chrome (latest)
• Version: Plyr 2.0.16

Players affected:

• Vimeo

Steps to reproduce

• Embed Vimeo as per docs

Relevant links

https://plyr.io/#vimeo

[aymenpeak]

it happened to me too !

[weskhaled]

me too

[sampotts]

Argh, Vimeo really is crap. I think it might be time to drop support. There's no way to hide their controls via the API so we had a kinda hack to hide them off screen (iframe was 200% height and then centered in the viewport) but clearly that's no longer working. Either they found it on someone's site or they discovered Plyr. A really downer.

I think the options are either we drop support or keep it but using their controls which would offer an inconsistent experience and frankly not as good looking.

It's a shame as they have some good quality videos but when it comes to embedding that content on your own website, YouTube far exceeds them and even they have their downsides.

[yuriykuzin]

As a temporary solution, I'm placing non-transparent plyr control over vimeo's one. And only in case of non-fullscreen, because in fullscreen the is no such problem for now.

Also, had to add defaultDelay to my fork of plyr to show plyr controls longer than vimeo's one.

[pocketarc]

This has happened to me as well, but it is possible to turn the controls off in the embed settings:

It's not perfect, and they then add a "play" button to the centre of the video, but it works well enough to make continuing to use Plyr viable. And the good news is Plyr can get rid of that Vimeo hack to hide controls now, since it's no longer of any use.

[sampotts]

Is it possible to turn them off for everyone? I was planning to just use their "native" controls for now and add an option to the config to turn on the custom controls.

[pocketarc]

I'm afraid it's something people have to do themselves. People can use an embed preset that turns controls off, and then assign it to every one of their videos, which does the trick (that's what I did for 100+ videos), but there's no way for Plyr to control anything.

Perhaps the best option is to disable the custom controls by default (like you already do in iOS), but allow people to use them with a custom config option, so those of us who are OK with the settings workaround I described earlier can keep making use of the custom controls bar (which of course, would have to be documented).

Either way, what a pain supporting Vimeo must be! Thank you so much for all the effort you put into Plyr.

[hatsumatsu]

Looks like these embed settings are only available for Vimeo PRO, Plus and Business members...

https://help.vimeo.com/hc/en-us/articles/224972808-Customizing-the-embedded-player

[pocketarc]

Yes, they are, sadly, which is why I suggested it not be a default workaround. They're there for those of us who use Vimeo/Plyr for business.

[danaburger]

Are there any insights into what's causing this issue? I can pass along information to Vimeo's dev team if there's something off with the interaction between those two systems.

[sampotts]

Hey @danaburger , it's always been their intention to display their controls on embedded videos. I just took advantage of a loophole that allowed them to be hidden. A loophole they've now closed unfortunately.

[danaburger]

interesting, what was the loophole? (if you don't mind me asking)

[sampotts]

So the usual way to display an iframe in 16:9 is to sit it in an container with 0 height and padding bottom of 56.25% (to create 16:9) and then make the <iframe> absolute positioned and 100% height/width. With Vimeo, I added an extra div in between which was set to 200% height and then positioned in the center of the outer div using a transform. This kept the responsive functionality but to Vimeo the container was really tall so their controls would sit outside the of the 16:9 container of course, hidden off screen. They've since forced their own 16:9 container within the embeds so my loophole/hack no longer works. I guess it was only going to last so long anyway.

[sampotts]

Obviously not something they'd like or support but I guess they have to make money somehow without resorting to ads.

[danaburger]

@sampotts Appreciate you providing those details. Vimeo did make some changes, but you can override that change by adding ?transparent=0 to the end of the player URL in the embed code. I hope that's helpful.

[jonnitto]

Unfortanly transparent is not a supported option in the vimeo player. So it has to append when the iframe is initialized.

[pocketarc]

@danaburger Wow, great find! @jonnitto's commit does seem to resolve the problem, but for some reason the play/pause indicators then stop working. Trying to figure out why.

Edit: Also, when it first loads, the controls bar is still there, so it might be useful to hide the video's iframe until it has loaded properly (when using custom controls, to avoid the flash of Vimeo's control bar).

[pocketarc]

That issue can be resolved by customising Vimeo's own embed JS file to include the &transparent=0 when first creating the embed. It means that we'd have to maintain a fork of Vimeo's player JS, but it resolves the issue flawlessly — it goes back to exactly the way it was before.

I'm sure someone might be able to come up with a better way to do it without customising Vimeo's player, but if not, this is the most straightforward. The change is a single line; it'd be easy to keep the fork updated until support for the "transparent" option was added to their oEmbed API. Combined with unpkg, it'd be easy to serve the custom player JS, and resolve the issue for everyone using Vimeo with Plyr.

[sampotts]

Great find @jonnitto! I wonder how long before they close that loophole though 😔

I think I can see why this is happening now - as their API is bound to the iframe and then the source changes, all events/bindings are lost perhaps?

I'm going to try initialising the Vimeo API with an <iframe> that I create first and see if that helps. I'm working in develop currently but I'll retro-fit it to master so those having issues currently at least have a solution. I wanted to offer this originally anyway as a true progressively enhanced solution but I think that'll wait for a later version.

I'm not sure if I'll get time tonight (it's 10pm Friday) but definitely at some point tomorrow. Will report back.

[danaburger]

@sampotts Vimeo is not planning to end support for the ?transparent=0 embed parameter :)

[sampotts]

Looks like the iframe solution works 👍 I've got it working in develop (which is still work in progress) but will port the changes over to master.

Nice find fellas.

[sampotts]

I've just pushed v2.0.17 with the iframe fix in. Let me know if you find any issues. There's some other small bug fixes in there too:
https://github.com/sampotts/plyr/releases/tag/v2.0.17

[bleepsandblops]

Hey @sampotts, really sorry that I haven't understood completely what was going on, but is the fix supposed to fix the middle Play button showing up just by updating plyr? As it hasn't changed anything here, it's still showing; but I might be missing something?

[friday]

@bleepsandblops: That's a plyr control. Vimeo doesn't have any middle button. Disabling specific controls is documented (see "options").

Edit: See danaburgers responseˇ My bad!

[danaburger]

@bleepsandblops, try enabling the play bar in your Vimeo embed settings again. The middle play button appears when the play bar is disabled (and when a viewer hovers over it)

[bleepsandblops]

@danaburger thank you so much! that did it!

[frumbert]

Glad it's fixed. Vimeo support is the primary reason I'm using this library - business users prefer Vimeo because it's back end is much better about ads and privacy and replacing content - (that and it's been easy enough for me to otherwise modify). Vimeo regularly breaks though, I hope this fix sticks for a while!