I'm not a web developer, but I was dabbling with 3D CSS transformations and animations and found that they didn't interact with :hover the way I hoped or expected. I wasn't able to readily find any disclaimer that this is a known problem, so I'm wondering if I'm just doing something wrong.
To reproduce the problem simply, start from this demo 3D cube animation here:
http://cssdeck.com/labs/simple-css3-3d-cube
Add this to the bottom of the style section:
#cube div:hover {
background-color: white;
}
I'm looking at that, using Chrome. I was hoping that, as both the cube rotated and the cursor moved (or didn't) the front-facing side containing the cursor would have a white background. But in practice that doesn't happen properly. If I scroll the cursor over the animation it picks out the correct panel to highlight but then it often fails to update when it should. Most noticeably, if I stop moving the mouse it doesn't seem to detect any change in what element the cursor might be hovering over.
Is this a known shortcoming? Does anyone have a solution?
It appears there's a difference in Chrome's Webkit engine vs Firefox's Gecko engine. Firefox continually runs to check a hover status, while Chrome does not.
I tested it in Chrome and Safari (both run Webkit) and they have similar results. They do not update the hover state if you keep the mouse still. Firefox, on the other hand, continually checks the hover area when the mouse remains in the same place.
Related
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.
using:
Chrome 36.0.1985.125
Foundation Orbit 5.2.2 with animation: slide
I have a slide show, 5 slides, at the top of my page. They are set to transition via slide every 3000 ms.
I first noticed the repaint issue described below due to Fancybox being called near the bottom of the page. While the Fancybox iframe was "popped out" there would be a quick white flash / flicker affecting everything apart from the iframe, every 3 seconds.
Using Chrome's inspector's Timeline view as well as the Rendering option to "Show paint rectangles" proved my suspicions correct.
Even when the slide set (the top of the page) is off screen, still every 3 seconds there is a page-wide repaint. With the inspector's Timeline, I can see a "heartbeat" every 3 seconds in the flow, even when scrolled all the way to the bottom of the page, including a large purple and green spike, where purple represents rendering and green represents painting. With the Rendering option "Show paint rectangles" I see, again even when scrolled all the way to the bottom of the page, a quick flash of every element on the page framed and tinted in green (being painted) every 3 seconds.
I've looked around quite a bit for "foundation orbit flickering," "orbit slideshow repaint" "foundation orbit repaint offscreen," and similar terms and have so far not discovered anything of use.
One or two pages I read mentioned a font change or font flicker at regular intervals relating to the slides' transitions. The "fix" (or workaround) there was to change the animation parameter's value from slide to fade. Trying this, I found that the repaint issue went away completely. However, I would prefer to use the slide transition.
I haven't been able to reproduce this in Safari or Firefox, but I also don't know what developer tools to use in either of those browsers that would confirm or deny whether the repaint is occurring (i.e. the equivalent of Timeline or "Show paint rectangles" in Chrome's inspector). Failing that behind-the-scenes proof, it is the case that in Firefox and Safari, with the Fancybox iframe popped out near the bottom of the page, there is no white flash / flicker, as there is in Chrome due to the repaint.
Any help would be greatly appreciated.
And yes, I realise that the Foundation Orbit slideshow is no longer supported.
Many thanks.
I'm working on a web page design and Chrome is wigging out when I change a stylesheet. I'm trying to switch between light and dark themes.
I have this <link> to start:
<link rel="stylesheet" href="/css/dark.css" id="theme">
To change the theme, I'm doing this:
$('#theme').attr('href', "/css/light.css");
I have code to actually toggle (loads dark if light is loaded, and vice-versa). Whenever the stylesheet of the non-default theme is loaded, it likely -- but not always -- glitches after I move my mouse around. For instance, after I first toggle the theme to the light theme:
It actually does repaint the full page with the theme for a split second, but then it turns the screen black (but it does not revert back to the dark theme, as the dark theme is not black; it actually has a dark gradient).
When I move the mouse around some more:
The white area expands in blocks over where my mouse is moved, until I move it over most of the page it goes back to what I expect. Or, I can resize the window and Chrome fully repaints the page as expected.
Removing the fancy tooltip doesn't fix the problem:
I've tried invoking a window resize event. I've tried using jQuery to show/hide the html and body tags to try to trigger a repaint. I've also tried deleting the theme's <link> tag entirely and adding a whole new one to the DOM. Alas, I see the same effect.
Firefox and Safari don't behave this way. But I absolutely have to get this working on Chrome. Any ideas?
Update (March 2014): This page is part of the web UI of GoConvey. It still renders fine in Firefox, and the glitching in Chrome at this point is less frequent and slightly different in its nature, but it's still there. Anyone is welcome to take a look if you are feeling generous.
Wow. Here's the CSS hack to fix it:
-webkit-transform: translate3d(0, 0, 0);
This forces Chrome to use the GPU to render the element. I no longer see the glitching.
Update about a month later: Okay, well, I've continued to develop this web app and now the glitching is back. Still trying to work around it. Now sometimes the whole viewport goes blank and I have to resize the Chrome window in order to get it to re-appear.
If anyone would like to try this and see the glitch live, the page is GoConvey's web UI (Chrome on Mac).
While testing an SVG animation I've run into a rendering problem in Chrome Version 23.0.1271.95.
The animated triangles seem to leave some black vertical banding.
This goes away if you tab away from the page and back or if you otherwise force a redraw.
You can find the animation test here:
http://bit.ly/HexaGridTest
And here's a screenshot:
Looking at other posts on similar issues it seems that the only way to eliminate this GPU-acceleration-related problem is to force a redraw at the end of the animation.
Someone suggested adding -webkit-backface-visibility: hidden to the SVG, but this didn't solve the issue for me.
Is there any alternative? Any flag or CSS property I could set to avoid the artifacts?
I have a rather strange problem on a site I designed. Every time you hover in or out of a link, the link element and in some cases its parent flashes white quickly. This happens on every link, not just the ones with transition effect or different hover color. On FF, everything works just fine. Also the white is not the bgcolor of body.
What makes it even more mysterious is that I haven't done any changes to the site. I only updated Chrome..
I would post an image too but as I am a new user I'm not allowed to, gotta do it as a link:
http://www.planetoidi.com/temp/hover.jpg
This is caused by a large class of bugs in Chrome which show a flash (white or black, depending on the bug) when transitioning to or from accelerated rendering. This can happen on hover when there is a CSS transition from the non-hover state.
A workaround is to ensure that the base state of the element is using accelerated rendering. One way is to add the following rule for your element (without the :hover selector):
-webkit-backface-visibility: hidden;
Source: http://www.sitepoint.com/fix-chrome-animation-flash-bug/