Firefox Mac preventing video with overlay from playing - html

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.
Demo page : http://www.googledrive.com/host/0B3INRRYhLi7cVHNKTzhMdnRjT3M
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:
If you click 'Change opacity to 75%' it will show the video through underneath. If you then click it then it will play just fine.
If you click 'Make overlay smaller' it will make the overlay not completely cover the video. Clicking on it will then play just fine.
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.
update
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.

Related

No Standard Full Screen Button for HTML5 <video>?

I have a video element that’s working beautifully with the standard controls in Safari (OS X 10.11 - El Capitan). I have play / pause, the scrubber, captions, and even AirPlay. …but there’s no full screen button. I swear I’ve seen that button on the normal controls before. The WebKit blog even has a screenshot with the button in an unrelated article (backdrop-filter is rad though, check it out).
Is this seriously not standard functionality?
I’ve added fullscreen to the video and source tags and even fullscreen="fullscreen" for good measure. The controls tag is working (I see the controls after all).
iOS’ controls are visually different and include the full screen button.
I’ve been hunting around and the most popular thing I can find is this super old StackOverflow article that basically says I need to use Javascript. That doesn't seem right. I feel like I’m taking crazy pills!
I suppose this could explain why so many sites roll their own controls using the JS hooks but it seems like a lot of work for expected functionality.
I realize I’m just asking for a ding in my pitiful reputation but I hope I’ve just missed something obvious.
Thank you in advance for your help / downvotes. :)
I was in a panic over the problem until I discovered that a <video> contained in a "popup window" instead of a regular window/tab is will cause the <video> tag to drop the fullscreen button in its controls.
My "page preview" happened to be launched in a pop-up window, and having maximized that, it took me a while to eliminate various factors before concluding that it was a popup vs. normal window/tab issue.
The behaviour that I experienced was in Chrome. I haven't tried it with other browsers.
Additionally: Also, note that within IFRAME also behaves the same way, dropping the fullscreen button, too (from the comments).
I figured this out, it was at least half stupidity.
Heading
I had the video element set to use max-width: 100% so it would fill the container on the page. I didn't think that would have any effect on the video's ability to go full screen.
No Metadata
The video didn't have any metadata to preload in the first place. I used an app to add a title to the file.
Does the fullscreen toggle button show up when you start playing the video?
According to Apple's documentation:
The webkitSupportsFullscreen property is not valid until the movie metadata has loaded. You can detect when the metadata is loaded by installing an event listener for the loadedmetadata event.
It seems there is some support in the video file that needs to be checked for before fullscreen support is enabled in the controls.
When viewing an HTML5 video on both Chrome and Safari, the fullscreen toggle button doesn't appear until the video has started playing.
EDIT: you might be able to get around this behavior by adding preload="metadata" to your video element.

Repaint time from 0 to 8ms, Chrome still not scrolling smoothly

First of all, let me explain what I mean by "smooth scrolling" here. When I rotate the mouse wheel by one "step", e.g. on Google Search results page, the page gradually moves up/down - the transition from the "before scroll" to "after scroll" states takes some time and is nicely animated. However, whenever I create a long page in html and try to scroll just one "step", there is no animation or transition on scroll - the page just instantly jumps few lines up or down. The average repaint time of my page takes about 5ms, with peaks up to 8ms, so I know repaint time is not the cause of that.
I know that such smooth scrolling can be achieved without any scripting, as for example the site http://www.thecssninja.com/ scrolls super-smooth on Chrome even with js disabled.
Why does Chrome choose not to scroll my page smoothly? How do I achieve smooth scroll without depending on JS, as CSS Ninja manages to?
PS Firefox does not seem to have that issue. How do I tell Chrome with my html/css that I'd like my page to scroll smoothly?
Either you can enable chrome smooth scrolling manually, which does not make sense for website development.
Or you can use some of the libraries to achieve that.
https://github.com/fatlinesofcode/jquery.smoothwheel
Sadly for chrome you cannot enable smooth scrolling through HTML, CSS or JS.
I know you're not after JS solutions, but I've never seen anything guarantee this outside of JavaScript, and karan's link above is certainly the smoothest example I've seen of doing this.
(Proviso: I'm using Chrome for Windows, not Linux. Apparently, that may make a difference.)
I use Chrome myself, and I always get the pages scrolling in jumps, not smoothly--even the pages you described as 'smooth' above step for me several lines at a time, including the Google results page. There used to be a flag available for this in Chrome, which allowed you to turn on smooth scrolling -- it could be accessed through Chrome's flags (go to chrome://flags/ to see those that are available) -- but it's now only available for the Linux Chrome platform. It may be available again in the future, but for now at least, it isn't. Hopefully, though, these experimental features will eventually find their way into Chrome, and render this whole issue obsolete.
Firefox, on the other hand, scrolls in nice smooth steps no matter what page I'm on--including my own local info pages which have almost no styling at all. IE scrolls smoothly, though not nearly as nicely as Firefox, while Opera behaves like Chrome, and steps through the pages several lines at a time.
I'm pretty sure that this is an issue to do with the browser, and not something that you can currently remedy with styling alone. Sorry I couldn't be of more help, but if you're doing this for a client, at least you'll be able to explain the issue.
I would highly recommend finding an alternate solution, but I have managed to find a solution to this exact problem for one of my websites. Akin to just using glitter glue to solve a leak in a wall, I discovered that including an iframe for a Google map on the page (even if it's hidden) somehow added in smooth scrolling. I have no idea how it works, but for some bizarre reason it does.
As I said though, I highly recommend not doing this, as its an extra (and sometimes lengthy) request made on each page to include an element most users won't ever see.

Two clicks required when only one should be needed on iPad/iPhone

I'm working on a site which is supposed to support both mobile and desktop devices. I'm using jquery-address plugin to make an image gallery which can use hash tags to be deep linkable.
But I'm noticing a problem in ipad simulator with iOS5 and iphone 5 where I have to click a category within the image gallery twice on the image gallery to get the event to work properly. It works fine on chrome/safari/firefox on OSX with one click.
So far I've only seen this on iphone/ipad. Any ideas about why desktop browsers work fine with one click, but iOS on ipad/iphone need two? I'm at a loss here. I can't tell if the problem is with my markup/javascript or an obscure bug in jquery-address/safari on iPad/iPhone.
I'm pretty sure this is due to your markup and having a hover state on .gallery-category:
.gallery-category:hover {
color: white;
cursor: pointer;
}
iOS doesn't support :hover in the normal way because there's no way to detect a hover state without a mouse. It usually sorts itself out on straight up a:hover states, but I'm guessing because your markup is a bit complicated (and there's a :hover state on the parent) it's causing it to break.
I think if you replace the above snippet to work on
.gallery-category a:hover {...
it will fix it (I haven't tried it on your code though)

Strange black blocks appearing in Chrome

For some reason, black boxes are displaying in random spaces in Chrome (latest build).
Some of these boxes are appearing outside of the main container, whereas some are appearing inline, covering content blocks. They appear randomly, usually after scrolling, and will often disappear when opening the inspector, hovering over elements, or scrolling down and back up.
For reference, there are some animations, box-shadows (which have been disabled with no luck), linear gradients, and position: fixed elements on the page, although this is not an issue with browsers other than Chrome.
This has been widely reported in user testing, although I have not been able to conjure up a fix. I am not sure if it is a CPU or graphics card issue, as the site is relatively lightweight and I am browsing with a new laptop with 16gb ram. My old Mac Mini, with 4gb of ram, does not produce this issue.
Any pointers would be most appreciated.
Update: This was a bug in Chrome and was fixed: https://code.google.com/p/chromium/issues/detail?id=142038
eddz filed the issue at crbug.com/new and over 40 people starred the ticket to follow along. It led to a few separate fixes in Chrome by the engineering team.
I had this issue with a website that was using transformZ (0) to force GPU rendering. When I removed this style the issue disappeared
This isn't an answer, but if you are able to somehow reproduce it maybe later on down the road:
Make a copy of the page locally, or anywhere, set the base href to the main domain, now start removing css links and js scripts from the bottom to the top until you don't experience the behaviour anymore, if you get to that point then the last script/stylesheet you removed is the culprit.
If you find the culprit file, now try finding the culprit line/section.
If you don't get to that point, it may be the browser, but it doesn't sound like it is.
It may also be linked between scripts/stylesheets and/or accidentally inherited.
We had experienced this weird blocks too on our website. In past we was using transitions, transitions was reproducing another bug "weird lines" randomly appeared on page and dissapear during scroll.
Now we start using transformX-Y, may be in some places Z too. And we have got this hell bloack blocks.
It seems something wrong in Chrome with transfom + transition animations. May be this bug appear when too much blocks animated at one time?
FF works fine.
I encountered these same boxes. For me, the problem was that I was using mp4 videos, which are deprecated in chrome, instead of webm videos.
I think is related to the GPU I had the same issue on my website. And it stopped happening when I turned on the Metal Rendering flag.
My website renders back bgs randomly while scrolling. It is really heavy on videos and animations and looks like chrome has so little GPU available that graphic intensive website doesn't work correctly on blink. I noticed that when chrome used webkit those issues didn't happen.
I this is a blink render issue.

Firefox - transparent png taking CSS background attribute's while firefox is refreshing cached images

Working on an image heavy website, discovered a strange bug(?) in Firefox. Any CSS background properties are rendered onto transparent png's. It occurs after the initial render, during the cache refresh. This appears as a flicker if you're using broadband but becomes extremely noticeable as you scale down bandwidth.
General progression of the issue seems to be:
Page and images rendered from cache
Firefox removes the cached images.
Firefox begins to reload images but displays a box with the CSS properties of the background.
I've recreated a (hideously colorful) example, but you may need to use fiddler, or another program with bandwidth throttling/emulation to see anything more than a flicker. Obviously, you'll also have to load once and then refresh to experience the error. And again, it's only in Firefox.
I have tried a plethora of various suggestions, none worked. Just need a fix, hacks will work as long as they don't effect other browsers.
EDIT: Here's a video so you can see it in action.
Since I cannot recreate the issue on my Firefox (10.0.2) on my computer (Win 7) with my particular hardware (which may or may not be a part of this problem), I offer the following as a guess at a solution, though one I would have assumed you tried already.
Target your img tags (preferably with some css more specific than below) that you have the issue with and try setting one of the following:
Either:
img {background-color: transparent;}
Or:
img {background-color: transparent !important;}
Update: Another Possible Workaround
Have javascript make the relevant img tags invisible to start and also bind an event to them so that when they load, they become visible again (JQuery example):
$('img').css('visibility', 'hidden'); /*not using "display" keeps layout*/
$('img').bind('load', function() {
$('img').css('visibility', 'visible');
});
I cannot test the above, so no guarantee it will work, but is another idea.