So there is a little function to create word by word text animation, but in the end of each word animation it blinks(like opacity 1-0-1 jump in a second), i tried to fix it myself and figured out that chrome for some reason doesn't like filter: blur(0) (0 or any low number).
Any tips to fix it? Because everything works fine in firefox and opera.
function fadeIn(quoteSpans) {
Array.prototype.forEach.call(quoteSpans, function(word) {
let animate = word.animate([{
opacity: 0,
filter: "blur(3px)"
},{
opacity: 1,
filter: "blur(0px)"
}],
{
duration: 1000,
delay: delay,
fill: 'forwards'
}
);
delay= delay+300;
})
}
Your code is technically correct, however the problem you are seeing is browsers inconsistency to properly implement new features.
This isn't really to say browsers do a bad job of this, but there is only so much manpower in a day, and every feature that's added has to be work on multiple hardware platforms and has the possibility of breaking already existing features.
On my computer your animation works just fine on chrome, often it's different video card drivers/hardware that causes errors like this.
So basically you have 3 options. You can open a bug report on chrome and wait for them to fix it.
You can figure out what hardware configuration is causing the browser to fail and ask your clients not to use that configuration (obviously a bad idea).
Or you have to think outside the box and figure out what's causing the browser to fail. Then think of a way to achieve the same effect without triggering the error.
In your example I would take an educated guess to say that setting a blur and changing the opacity at the same time is too much for your browser to handle.
So perhaps what you can do instead of adding both effects to the same text element, is only put your blur animation on the text, and put a white div over the text.
Leave your text opacity at 1, but fade out the white div from 1 to 0. Then users will see the text "fade in" as the div above the text "fades out".
That will prevent the browser from having to deal with opacity and blur on the same element and will probably fix your problem.
Related
My users and I are running into a rendering glitch in Chrome only (on both Windows and Mac) where an overlaid div that I'm using for on-hover tooltip-style "popouts"(see first image below) does not get rendered properly in certain cases (see second image below). In all other browsers I've tested, it works as expected.
Here's how the hover popouts are supposed to look (and what happens in Firefox, Safari, IE):
Here's what happens in Chrome:
You can see it in action on this site if you look at May 24 using a browser window width of ~ 1200px (significnatly wider or narrower windows do not seem to work). The glitch only affects the popouts in the bottom right of the menu that are popping left, e.g. those on May 24. Hovers using the same exact mechanism higher up in the page work just fine. Glitched popouts are invisible (except for part of the carat), but if you click on the link to lock the popout in place and then hold left click while moving your mouse around as if to "select text" in the area where the popout should be, it will then render partially. Also if I open dev tools and try to select the popout, it will render just fine at that point.
I've been looking at this all day and trying different work arounds with opacity, z-index, etc. and getting nowhere. Does this glitch ring any bells for anyone? Is there a way to force Chrome to render the div, once its been positioned and unhidden? I'm fine with any work-around or hack.
I use a custom (and fairly complicated) jquery plugin for popouts. If it would be helpful to see the non-minified javascript for the plugin, I can post or provide a link to that, but general guidance that leads me to a work around will be sufficient to be accepted as an answer.
Edit: My Browser Build: 26.0.1410.65
(Per my comments)
This does indeed seem to be a bug in Chrome, though without a smaller test case to reproduce it, it could be very hard to track down. You may want to report it to the Chrome team with as much information as possible.
In support of my "it's a bug" assertion:
The hidden/clipped elements become visible when they are selected.
The elements underneath the hidden/clipped elements are not clickable.
This indicates that z-index and height is correct.
It only happens under very specific circumstances; the rest of the items with the same style work fine. The same item may work fine at a slightly bigger/smaller screen width.
Applying a 3D transform fixes it.
The problem goes away when I apply a CSS transform such as scale3d or translate3d. I imagine this is because certain CSS properties cause the browser to switch to GPU acceleration.
In this case, switching to the fast path for rendering seems to alter the drawing sequence enough to fix the problem.
Super hacky but this fixes it for me:
$('.drop-link.food').on('hover',function() {
$('.tool-tip').css('overflow', 'hidden').height();
$('.tool-tip').css('overflow', 'auto');
});
Obviously this isn't a "good" solution, and even remaining hacky you could probably optimize it to only force the redraw on the tooltip it needs to, but hopefully it helps...
Another clue:
$('.drop-link').on('hover',function() {
$(this).siblings('.tool-tip').css('display','block');
});
This won't fix it right away, but it seems like if this is there, once you've hovered on something, it will work the next time you hover on it.
Not sure if this helps with your situation, but over the last couple of days I've started to notice that certain site elements on Facebook and Weight Watchers no longer show up. Specifically it seems to be affecting items that (I believe) to be controlled by or dependent on Javascript. When I call up these sites in Firefox and Safari they work as expected.
I'm currently fighting a very frustrating bug on Safari, and I'm not sure where else to turn.
It seems most elements (but not all, and I can't discern the differentiating factor) that will trigger a focus event will cause all elements on the page that are transitioned or animated to jump ~2px to the top and left. And this only occurs on the first focus event after the page loads.
It's a little annoying to see the bug, as it's in the logged-in portion of droplr.com, and I have been completely unable to distill down a simpler case on JSFiddle.
If you have/create an account and log-in, click on this edit icon for a drop:
You'll see that on the first focus of the page, things jitter. Here's the timeline when there's a single drop on the page and I trigger focus on an offending element:
With more drops, it's just more of the same, but it seems to max out around 40 paints. And the profiler doesn't suggest anything nefarious. Just a trip through jQuery internals.
If instead of laying elements out via a translate3d or matix3d, I simply use top and left, this bug goes away. After hours and hours of debugging this, I'm at a complete loss.
Hoping someone has seen something similar, could take a look, or could give me advice on debugging next steps.
Thanks so much!
Update: Dave Desandro suggested it was the 3d acceleration kicking in, so I tried it out with a translate instead, and sure enough, that did not cause the jitter. I have no idea why the hardware acceleration would be firing up with a focus event though, and only once.
I've tried setting a transformZ of 0 on page load to go ahead and ramp-up the hardware, but no luck there, either. Any more ideas are welcomed.
I've had this issue a while back and honestly I don't remember what exactly was the cause but here are some of the steps I followed:
Check that you don't have hide() and show() for the same element in the next line or vice versa.
Example:
el.show()
el.hide()
Change Custom fonts to "Arial"
For the elements you don't want focus events add this code at the bottom of your scripts:
noFocusElem.off('focus');
This will make sure to remove any focus handlers you might have added by mistake
Finally place your css before any scripts. It's a know fact that adding css rules after an inline style has been applied may cause jitter especially if you're using line-hieght property
Hope this helps :)
I've had this happen when using custom font kits. Could this be the issue? Some events cause custom fonts to re-draw, which can cause a ever so slight "jitter" in page display.
Sometimes, manually setting heights and widths on all the parent HTML elements can reduce the flicker.
I know this question was posted a while ago and this is a bit of a long shot but here goes:
Maybe as a starting point go back to chrome and look at the composite layering:
Hit this into the address bar:
about:flags
You will be able to enable composite borders from within there. The red borders generally indicate a rendering issue:
http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
What I have found from time to time is that although there are rendering issues in Chrome the browser copes pretty well with hiding them from me. In other webkit based browsers however the result can be more noticable (i.e. android).
I've also seen flickering occur when z-indexes are being used in conjunction with content that is being transformed.
Either way it would be great to know how you resolved this issue (if you did). Post an answer to your own question perhaps?
A way to avoid spending time fixing load time twitches; you could set the page to hidden then make elements visible with the load. If your page is slow to load, you may want to have a spinner default to visible, then have load hide it. Then you could come back to the issue when you have nothing better to do.
Just my 2c worth.
The first thing I would try:
First in chrome, whack in 'about:flags' (yes I know you're not using Chrome). Find the 'Composited render layer borders' and turn it on. Once this feature is switched on you'll get a rough idea of what is being rendered/hardware accelerated.
See: http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
and look for any rendering problems. These are normally caused by z-indexes. Play around with any z-indexes and hide/show certain elements until the rendering issues are resolved. Then work from there. translate-z hacks and opacity can also cause problems.
From experience I've found rendering problems in other webkit browsers can be diagnosed using chrome. Flickering is a common occurrence on the stock android browser.
Secondly: take a look at the focus event itself and try things like preventing the default behaviour. Seems like a long shot to me but give it a go.
I haven't tested this, so I will be very surprised if it works... but here's an idea:
$(document).ready(function() {
$(document).focus(function(e) {
e.preventDefault();
});
$(document).click(function() {
$(document).unbind();
});
});
I've been running into the same issue recently and found something that fixed it in my case.
Check for anything that's hidden offscreen like:
text-indent: -9999px;
left: -9999px;
Removing any instance of these from the 3d accelerated elements (including children) stopped the content jump on focus for me.
I know this is a long shot because it is a large script and I doubt anyone will want to read through all this but here it goes.
I have an animation function that animates the style properties of a list of elements. This function can be found here. Now I know all about cross browser opacity and I can set it manually i.e. I can set the opacity of an element to .5 (50 in IE's case) and it works perfect in every browser. Just when I try to animate my opacity property through my function it does not move.
As you can see in there I have a lot of code just to get IE's method of alpha(opacity=x) working.
For an example of it please see this fiddle. Sorry about it being so messy. If you click the paragraph tag that says Fade to .5 opacity on click. in any browser other than IE it will fade to 0, not .5 because I am testing stuff. Now if you click the same tag in IE nothing happens.
I doubt anyone will be able to help with such a complicated and specific problem but any suggestion will be much appreciated.
Looks like you're implementing your opacity logic twice, both in css() and animate(). That's bad design IMO no matter how much you're aiming for high performance. Once you fix that, animate() will be dependant on a working css() function, and since that works, animate() will work.
Here is my site: http://www.dreamweddinggroup.com/redesign and I'm having a hell of a tough time figuring out why in gods name my fadeIn, fadeOut and corner() functions won't work in IE8. They were working for a time, but now they have broken and I can't for the life of me figure it out. Can anybody see anything that would cause the problem here?
To see what I'm talking about, if you were to click on the "About Us" link at the bottom of the page, you should see the text fade in. Then if you were to click on "Why Dream Wedding Group", the "About Us" text should fade out, and when it fades back in, you would see the new text.
Hey I was having the same trouble. I was trying to fadeOut an IE image and fade something new in like so :
$(".edit_photo_link").click(function(){
$(this).fadeOut("slow", function(){
$(this).next(".throb").fadeIn("slow");
});
});
Which wasn't working. But the FadeIn was! So guessing that this was processor getting eaten up by IE8 (not IE7), I just changed it to this :
$(".edit_photo_link").click(function(){
$(this).fadeOut("slow", function(){
$(this).hide();
$(this).next(".throb").fadeIn("slow");
});
});
And IE8 users don't get that extra loving of animation.
I had similar problems with a stack of absolutely positioned divs. I wanted to simultaneously fade one out and fade one in. Code that worked fine in FF/Safari would not work in IE8: The fadeOut() wouldnt fade, only the fadeIn().
I found solution was to use CSS to set the z-index of the element to be faded-in to be at the top of the stack:
$('#fadeoutdiv').css({zIndex:90}).fadeOut(2000);
$('#fadeindiv').css({zIndex:99}).fadeIn(2000);
I'm finding that IE8 has terrible performance using fadeIn myself with just a small image or text area. I think the engine is basically very bad at alpha blending! Because you're trying to fade fullscreen images, the performance is so slow that you just don't see the fade. In my case, I'm seeing CPU usage rocket to between 50% and 100% even on fairly powerful desktop with a decent graphics card. My client is having problems because every time this fade happens (every 5 seconds or so), video that is also playing starts skipping and being generally unstable.
Another site I'm working on is http://www.urstreams.com , if you hover over the boxes you will see a description appear also using fadeIn. If you mouse over all the boxes at once, so all the descriptions are appearing and disappearing at the same time, all the animations grind to a halt and CPU again rockets skyward.
Bit of a nightmare really, but at this stage I would recommend against any alpha blending animation in IE. The common theme in all these cases seems to be that blending is occurring over images. Perhaps this is the problem, as common jQuery samples and possibly tests / benchmarks tend to focus on basic scenarios such as plain text appearing over plain background tests?
I too have noticed this phenomenon with IE 8, though it seems to occur no matter what my element is floating above. I had an empty 4x4 px DIV that i was fading in and out on an interval (interval at 400ms, then element.fadeIn(100).fadeOut(500)) to debug element positioning and it was completely obliterating one of my cores! It took me a while to figure out why IE was constantly hitting 50% CPU while Chrome and Firefox barely broke a sweat -- I figured I had a rogue greedy loop somewhere until I scanned across my interval.
Fire up IE and your task manager and head over to http://www.hv-designs.co.uk/tutorials/jquery/all.html for a little test. Sort your running processes by CPU desc and watch IE rise to the top on every test (20-40+% of my 1.2 GHz dual-core Intel SU2300 for the duration of the fade +/- a few hundred ms), even for the simple text paragraph! Running the same test in Firefox or Chrome doesn't even break 10% usage for me.
I have a simple unordered list that I want to show and hide on click using the jQuery slideUp and slideDown effect. Everything seems to work fine, however in IE6 the list will slide up, flicker for a split second, and then disappear.
Does anyone know of a fix for this?
Thanks!
Apologies for the extra comment (I can't upvote or comment on Pavel's answer), but adding a DOCTYPE fixed this issue for me, and the slideUp/Down/Toggle effects now work correctly in IE7.
See A List Apart for more information on DOCTYPES, or you can try specifying the fairly lenient 4/Transitional:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
Just let IE6 flicker. I don't think it's worth it to invest time in a dying browser when your base functionality works well enough. If you're worried about flickering for accessibility reasons, just sniff for IE6 and replace the animation with a generic show() and hide() instead. I recommend avoiding complicated code for edge cases that don't matter.
$(document).ready(function() {
// Fix background image caching problem
if (jQuery.browser.msie) {
try {
document.execCommand("BackgroundImageCache", false, true);
} catch(err) {}
}
};
Apparently.
Oli's fix only seems to apply to flickering backgrounds, which is not the case here.
Ryan McGeary's advice is solid, except for when the client/your boss absolutely demand that IE6 not act like it has fetal alcohol syndrome.
I found the solution here: Slide effect bugs in IE 6 and 7 since version 1.1.3
Added a doctype declaration to the top of the file (why wasn't it there before? who knows!) and the flicker vanished, never to be seen again.
From what I've heard and tried (including the other suggestions here) there are still situations where the flicker will continue to be noticeable, especially when you don't have the choice of easily leaving quirks mode.
In my case I had to stay on quirks mode for now and the other suggestions still didn't fix the problem for me. I ended up adding a little workaround until we can finally leave quirks mode:
//Start the slideUp effect lasting 500ms
$('#element').slideUp(500);
//Abort the effect just before it finishes and force hide()
//I had to play with the timeout interval until I found one that
// looked exactly right. 400ms worked for me.
setTimeout(function() {
$('#element').stop(true, true).hide();
}, 400);
This code does not depends on the browser (no browser detection), works great and reproduces the behaviour of the method .slideUp
$("#element").animate({
height: 1, // Avoiding sliding to 0px (flash on IE)
paddingTop: "hide",
paddingBottom: "hide"
})
// Then hide
.animate({display:"hide"},{queue:true});
Dunno if someone will read this answer, but here is a workaround for those who, like me, can't add a document type to the page (thank you Sharepoint 2007 default templates) without spending a few days on a complete template revision.
On a DOCTYPE-less document, the flickering occurs when an element height reaches 0. So the workaround I've found is to animate my elements to an height of 1px, rather than 0.
Like this:
$(".slider").click(function (e) {
$(this).animate({"height" : "1px"});
});
Hope it will help.
N.B: don't forget that in order to slideDown the element, you have to previously store its initial height somehow (node property, rel attribute hack, etc).
I'm working with a carousel that has marked-up copy over some background slides. The slide transition is a fade. Everything's fine so far.
But some parts of the copy fade-in after the slide loads. And then fade-out right before the slide transition. This copy, an unordered list of links (UL > LI*2 > A), faded-in over the slide background. This, too, is fine in every browser except IE. IE had a flickering background on the UL.
What was happening is that there were two simultaneous fade-Ins running: the background image on the slide & the UL. I used sergio's prototyping setTimeout function to run the UL fadeIn() after the slide had completed loading. Then, I called another setTimeout to make the slide transition right after the UL fadeOut().
setTimeout is your friend when combating IE flicker.
We had the same problem today. Not only in IE6, but also in IE8! I've fixed it by hiding the div somewhat earlier, by using a timeout:
var pane = $('.ColorPane');
var speed = 500;
window.setTimeout(function() { pane.css('display', 'none'); }, speed - 100);
pane.slideUp(speed);
Hope it helps some of you out there.
I posted a quick fix solution over at http://blog.clintonbeattie.com/how-to-solve-the-jquery-flickering-content-problem/
In short, add overflow:hidden to the containing element that you are sliding in/out. Hope this helps!