I'm having a problem using the jquery hover events. I've created a reduction of the problem. You can find a working demonstration here. I can reproduce this after moving the mouse around in IE, FF, Opera, and Chrome.
I'm using queued animations in my mouseover event. Roughly 1% of the time, the color of the td elements is left as #0f0 after the mouse has left the td though. This should not be. The mouseout event should guarantee that eventually all tds turn back to #00f after a time has passed.
Update 2:
I've now reduced this probably about as far as it will go. No mouse events used at all. It's started working better in Opera, but now IE is a total cluster.
Anyway, I'm using a button to trigger this:
function ani() {
$('td')
.stop()
.animate({backgroundColor: '#0f0'}, 3000)
.animate({backgroundColor: '#00f'}, 3000);
}
See it here.
Update [n + 1]:
I just can't leave this alone. I've determined that the animation actually is occurring. It's just not automating the background color. I've done this by adding text and animating the background and foreground in unison. Under normal conditions, you should never see the text once it starts animating, but sometimes the background gets "forgotten", and sometimes the foreground. This indicates to me, that a jquery animation is actually occurring, but it is just not animating all the attributes it was instructed to. For the curious, see it in action here. (warning: IE chokes pretty hard on this)
Ok, going to play some video games now.
I don't understand how you get your 1% figure. I'm not sure about what behavior you're seeing, but in both FF3 and IE8 I get this ugly illegal-property-value error as documented here: http://dev.jqueryui.com/ticket/4251. More relevantly, a good dozen of them aren't changing colors, even if changed to simply a single-color animate.
Fixing that line in the jquery.color.js and both FF3 and IE8 work like a charm, although IE8 white-screens, it recovers eventually.
jQuery is great for managing the DOM, not so great for effects. In my experience, the UI stuff is painful to use and has always had issues. The framework itself, though, has always treated me well.
Related
Call me crazy, but I'm working on a game using vanilla DOM and TypeScript. It's not action-heavy, but there are some animations going on, which are driven from JavaScript (too complex to do in CSS).
I'm already applying the common trick of translateZ(0) (called null transform hack or less accurately silver bullet) to pull animated elements into their own rendering layer, and I'm animating nothing besides compositor-only properties (transform and opacity). This works beautifully: during the game, everything feels buttery smooth, even on older mobile devices.
The problem is during the start of the game. At that moment, about 70 individually transformed and animated elements enter the page one by one over the space of a few seconds, by animating their opacity from 0 to nonzero. This is causing visible stutter during the animation.
My guess was that Chrome is being too clever here, and will only rasterize each element at the moment it first becomes visible. A quick check with the dev tools confirms this, as there's a lot of rasterization going on even during the animation:
I would prefer to rasterize all these elements once, before the animation starts, and only then trigger the animation. But how can I force rasterization of elements that aren't yet visible, without showing a flash of them to the user?
I'd be happy with a Chrome-only approach, but cross-browser would be even better.
Update: found possible cause, when I confirm it I will post it as an answer
I found something interesting about IE behaviour.
Opposed to the example I posted on jsfiddle, my original page shows an image in the background (sorry for omitting it, I considered it not relevant). Not as a css background property but as an img element that comes before the divs with the mouseenter/mouseleave event handlers. I do not use z-index property (and I already confirmed that use it changes nothing) I found that when this is the case (an img element followed by absolute positioned divs that should render on top of it) IE only fires mouseleave/mouseenter events on visible parts of the divs. In my case, I discovered this by adding (border-style: solid) and a (border-width) of considerable size to all the divs. IE fires mouseenter when mouse pointer enters the div's border and then fires mouseleave when mouse pointer is no more over the border pixels even if it is inside the div (probably because the div is transparent). If no borders (as my original code) no mouseenter events.
In jsfiddle this was not reproduced. But if I add the img element should be 100% reproducible.
Possible workaround (I will test it right now and update): div background pixels must not be transparent or mouseleave will be fired right after the pointer is no more over the border pixels, if no borders then no mouseenter/mouseleave will be fired. Use a png background image for the divs with all pixels 1% opaque should do the trick. Maybe the css opacity property (without any background image but with a solid background color) may work too.
More info:
my doctype is <!DOCTYPE html>
I need the background image to be an img element, is not practical
in this case to use a css background property.
Original question:
IE 10 console is not providing any useful information. I started to use console.log in different parts of the script and come to the conclusion that mouseenter and mouseleave aren't fired for IE 10, don't sure in other IE versions. Works OK in Chrome and Firefox, and probably Opera.
This code result in no output in the console (for IE). It should at least prints "IE TEST 2".
console.log("IE TEST 1"); // OK
$(".show_on_mouseenter").mouseenter(function (evt) {
console.log("IE TEST 2"); // nothing is print
showContent(this);
});
$(".hide_on_mouseleave").mouseleave(function (evt) {hideContent(this)});
console.log("IE TEST 3"); // OK
For now I will try to emulate mouseenter/mouseleave using mouseover. But It would be great If the code just works on IE as It is now.
I tried to replicate only the relevant part of the code in jsfiddle. This time It worked for IE 10 too. I'm doing nothing really before those lines of code, maybe are my styles that are causing the problem. I modified my css to make the content divs and control divs visible from the start and they position and size is as expected in IE 10. My original hideContent and showContent functions have more code that the one I showing at jsfiddle but they aren't the problem because in my IE 10 they aren't being called as the previous console.log() line is not executed.
Code at jsfiddle showing how the script should behave. You move the mouse over the div, and another div appears, then you move the mouse out of the first div, and the content is hidden again. You will see a lot of suspicious values like "left: 14.321px". That is because my original code calculates left, top, width and height and produces not truncated values, as every browser I have tested accepted those values, I simply let them as doubles. Also some of them are as percentages, but in jsfiddle I used px in all cases because I'm entering them manually.
http://jsfiddle.net/xhzCL/
For some reason this code works in IE 10. jquery version is the same I'm using. I cannot replicate the problem in jsfiddle.
More info: Console is clear except for my own console.log() lines. I'm downloading my page from an http server running in another machine connected to my router. I remember something about an IE security police causing troubles with scripts of pages loading from intranet. May be this the problem?
The reason why the console is clear except for the console.log() lines is because there is nothing wrong in the Javascript code. Nothing wrong with the css or html. The problem is how IE 10 (and probably other versions of the same browser) behaves.
It seems that IE understands that mouseenter must be fired when the mouse pointer enters a visible part of the element and mouseleave must be fired when mouse pointer leaves a visible part of the element. This is not the case if nothing is below the element (visually) but things change when there is something below the div and due to div having no content or background-color the other element's pixels can be seen through it. Adding the css properties background-color: white and opacity: 0.0001 easily makes IE behave like all other browsers for this specific situation without the background-color becoming noticeable to the eye.
The following links must be visited using IE 10 (probably 9 and maybe 8) as other browsers (Firefox, Chrome, Opera, Safari) will fire the events in any case.
Demo reproducing the problem: http://jsfiddle.net/xhzCL/5/
Demo solving the problem: http://jsfiddle.net/xhzCL/6/
Update: by using two inner divs is possible to have visible borders and still have consistent cross browser behaviour: http://jsfiddle.net/xhzCL/9/
The difference are in these two css lines:
background-color: white;
opacity: 0.0001;
Or with jquery:
$(".show_on_mouseenter").css("background-color", "white").css("opacity", "0.0001");
Note that the proposed solution will hide also the borders of the div that should fire the mouse events. That's OK with OP needs, may not be OK for other situations. Try to remember where the div was in demo 1, then go there with the mouse pointer, the text will be visible while the pointer is over the full div body, no matters where exactly, while in demo 1 the text will be visible only when the pointer is over the border's pixels and will hide when the pointer is near the center of the div (opposed to the behaviour of all other browsers).
If OP had included the img element from the beginning others would run into the same problem and found a similar solution. Sorry for that, I was sure the img was not related to this and paste the full page code into jsfiddle was not practical.
Try using this instead
$(".show_on_mouseenter").on("mouseenter", function (evt) {
console.log("IE TEST 2"); // nothing is print
showContent(this);
});
I've built an HTML5 based solution that let's me drag and drop items around to change their order in a list, and it works great in Chrome, IE, and mostly in Firefox. There's just one scenario I've identified where it falls down:
In Firefox, when an item is dragged at high speed across one drop target into another, dragleave doesn't always fire. dragenter and dragover events are fired as expected for the item that's passed over, but (sometimes, when you do it just so) dragleave is not.
I've got no simple example of this one at this point, given how entangled it is with what I'm working on, but you should be able to reproduce it on the fully complicated version. The events log to console, for your ease of reference, and the relevant code starts around line 700 of the js file. Visually, you'll see the insertion indicators stick around when they shouldn't because the function that removes them never got called.
At this point I've more or less convinced myself that I'm not doing anything wrong, and that this is an issue with Firefox, but I figured I'd ask some experts. Anyone else run into this? Is there an existing bug for it I just couldn't find? Thoughts, suggestions, ideas, or what have you?
Edit: Added a simple fiddle to demonstrate this.
I have a container div that holds about 20 more divs that float left. When I resize the parent div with a javascript animation using Tween.js the floats don't reflow to the new size unless I mouse over one of the divs.
It seems like something is preventing the page from refreshing.
I'm thinking maybe there is a way through javascript to force the display to update?
UPDATE:
I've put it on JS Fiddle:
http://jsfiddle.net/mattlundstrom/fNUhn/
Click any thumbnail to toggle the animation.
This version uses TweenLite to animate the "Left" CSS of the #project-container. Notice how you must move your mouse after the animation to get the container's contents to reflow.
I get this result in Safari 5+ OSX and Chrome 20+ OSX. Works as expected in Firefox 13.0 OSX.
UPDATE 2
Video of what I'm seeing:
http://f.cl.ly/items/1R1n2s0U3I3c1M3s2K0T/lundstrom_float_issue.mov
I was able to recreate your issue just as you said. It seems that it is an issue with webkit redrawing or measuring the elements after an animation or transition.
This isn't the best solution by any means, but for the time being at least it will work and hopefully what I found will help other people to be able to find out more.
If you add an onComplete to the animation, and trigger the .project mouseleave, it looks to work fine:
function completeAnimate(){
$('.project').trigger('mouseleave');
}
function contract(){
// PROJECTS CONTRACT RIGHT
TweenLite.to($('#projects-container'), .5, {css:{left:"300px", opacity:".5"}, ease:Expo.easeInOut, onComplete: completeAnimate});
}
So here is my jsfiddle which has a few tests and other animation tests so that you can see some of what I tried.
jQuery animate() and css keyframe animations have the same result as the Tween code you are using, HOWEVER, a straight style update works fine.
$('#projects-container').css('left','300px');
No issues with that at all, but of course, no animation either.
Some other things I noticed was that if you take out the .project event bindings, it still doesn't redraw correctly, however if you move you mouse it still doesn't. It simply stays that way.
I also tried forcing an element redraw using a few tricks you can usually use to force a redraw. I tried this oncomplete and at intervals after the animation begins, but had no luck with any of it.
You can also combine the two tweens into one with the properties on both, just an FYI.
Hopefully this will help someone find the true issue that's going on with the webkit transitions.
I've got a strange error with IE8 and postcode lookups. It may not be postcode lookups as such that's causing it - just an AJAX call that modifies a select. I've set up a test page here. If you click on Find Address, and then double click (quite quickly) on one of the addresses that is within the boundary of the red-bordered div, you see the below bug in IE8.
Note: I'm finding it inconsistent to reproduce the bug, but if you scroll the list of addresses right to the bottom and then double click fast on Holly Cottage it should reproduce the bug.
If anyone can shed on light on this quirky behaviour it'd be much appreciated. Is this an IE8 bug?
I've found the problem - browsers do not like having javascript:void() set for the href attribute. If you want to have a working anchor whose default action is canceled, then use # for the href attribute, then have the event handler for that anchor return false to cancel the browser's default action.
Erm... right... sorry for my eagerness to post an answer and not double check that the problem was properly solved.
I'm finding it difficult to find the problem. I'm only going to hazard a guess here: the two effects running and ending at the same time confuses IE8, causing the div to be set to a height of 1px. This of course assumes a bug in the jQuery implementation of the effect queue, which I definitely cannot vouch for. It's just my theory at the moment - my unfamiliarity with IE developer toolbar prevents me from investigating further.
It's a problem with You running animations I suppose.
Your asynchronous action triggers some sliding animations.
First:
Try logging endings of all animations (put a callback function in the slide* call and log some text to console.) to see if they run in correct order - I suppose they don't and that's the problem.
Second:
Try adding .stop() before every asynchronously triggered animation so that it breaks other animations working at the same time.
Third:
If the above didn't help try this for every animation:
if($(this).data('running')==0){
$(this).data('running',1).slideUp(function(){$(this).data('running',0)});
}else{ /*call with timeout or ignore...*/ }
It's a basic semaphore on an element.
OR
You can use .animate and animation queues in jQuery properly, but it'd be a bit of an overkill for this case (I think).
My first reaction is it may be a CSS issue. If I find the default value, and click the 'Find Address' link one time, I see a similar (though not identical) layout problem. The height on each section looks collapsed, as if the floating sections aren't picking up the correct content height. If I incrementally specify a height on each contentRow or switch the display from block-none-block on pcodeLookupAddressEdit_risk_address, the formatting is corrected.
I don't know the specific cause, but, you may want to check the CSS and the show/hide behavior on the slide.