Unfortunately YouTube only counts views to videos when you click directly on the YouTube player itself. This is to prevent fraudulently high view counts. One technique if you don't want to show the YouTube player initially is to put an opaque overlay and graphic over the top with pointer-events: none
. When the user clicks on your overlay they will actually be clicking on the YouTube video so the view is counted. You then capture the 'playing' event and hide the overlay exposing the player underneath.
I have a graphic on my homepage and when you click it plays a YouTube video. Before anyone cries 'clickjacking' I'm not trying to trick anyone - there's a play button in the graphic so you know it's a video.
This works completely fine for me for everything except FireFox on Mac OS. I am using the latest version - currently 34.0.5 in my tests.
If you run this in Chrome / FireFox Windows / Recent IE version and click on the green overlay the video will play and you will hear music.
Note: Of course in my real page I capture the isplaying
event and hide the overlay.
Firefox is obviously doing some kind of clickjacking protection. If it thinks that you're trying to trick the user with an overlay over the video then it won't play it. However it is really bizarre to me that it doesn't also do this on Windows.
There are two ways to allow the video to play on Mac FireFox - both involve partially revealing the Youtube video underneath:
The most bizarre thing of all - when you view it in an iframe it works just fine (this is why I'm using a GoogleDrive link above that opens fullscreen) and not something like codepen/jsfiddle http://codepen.io/anon/pen/GgrZNN
I'm really looking for a workaround that doesn't involve if (firefox && mac)
. If this is documented somewhere in mozilla docs I haven't found it.
PS. Obviously browsers without pointer-events
have to be treated differently with an on-click event. That is not shown in this example.
(I'm using Browserstack.com to test, but it does the same on a real mac.)
I get the same issue Firefox Mac (and have yet to upgrade to Yosemite), but it seems to me you have pretty much already solved your own problem. The simplest solution that I can see would be to add an extra overlay layer beneath your current one and set them both to opacity 0.98 (which seems to be the highest you can go and still have the click work — at least in my tests).
Obviously it will depend on what you hope to show on your overlay, but for my tests locally I set the under-overlay (sorry, ridiculous name) to black. This meant that the video underneath was imperceptible. You could probably even go a little lower with the opacity and still block everything out with two layers, just in case the opacity thresholds for the click blocking are different across versions of Firefox.
.x-overlay {
opacity: 0.98;
...
}
.x-under-overlay {
opacity: 0.98;
position: absolute;
background: rgba(0, 0, 0, 1);
width: 100%;
height: 100%;
overflow: hidden;
pointer-events: none;
}
NOTE: One downside to be aware of when using even slight opacity. For certain browsers (or at least versions of browsers) text that appears in a layer that has opacity can end up with buggy or missing anti-aliasing. But this mainly occurred in much older versions of Firefox and Chrome.
Ok this was driving me a bit round the wall, or up the bend, or which ever strange phrase that can be used to describe the experience of continually expecting one thing, but consistently getting another... which has eerie similarities to the definition of crazy.
Why on [insert home planet here] did this work for Codepen, but not in my own localhost-served iframe...??
After attempting a number of different things I spotted the sandbox
attribute, which I really should have noticed before; especially considering all the strange trickery it can enable and disable with native browser processes. A quick trial and a few errorings later, and it seems what allows this to work for most of those online-code-fiddlers is the following:
<iframe src="index.html" sandbox="allow-scripts allow-same-origin"></iframe>
Still haven't found out exactly why, but if I enable the above on my localhost frame it starts working without the need for the opacity trick. I guess it must cause Firefox to route through a different process, or perhaps it just disables some kind of cross-origin clickjacking protection.
A very odd state of affairs... this is the kind of oddity I would expect from Chrome! Not good ol' Firefox.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With