while working on a project we come up on a bug which presents only in IE browsers. Here is JS fiddle: http://jsfiddle.net/tuHew/1/
Steps to reproduce:
1) Click on the middle div with text inside
2) Move your mouse out of result view
3) See frozen hover state only in IE
It works just fine in all the other browsers but it seems that in IE when element is removed from DOM it holds current element state in memory and when it's reinserted it already misses "hover out" event and any style which is associated with ":hover" pseudo class is frozen until you hover over with your mouse.
Does anyone know if it's IE bug or IE "feature"?
edited: try to see difference in IE and Chrome/Firefox !don't forget to move your mouse away immediately after clicking inside div!
Related
I have an HTML grid where we use arrow keys to navigate the cells (like a spreadsheet made of divs). Each cell has an INPUT textbox. We use javascript to catch keyboard arrow keys to move around the grid. This has worked fine in all browsers for over a year. Now, with Chrome 39, the grid will no longer scroll properly so that the input with focus is visible on screen.
Here is a fiddle to demonstrate the problem: scrolling list.
// This causes scrolling into view on focus to stop working
$('#grid').on('focus','input',function(e){
this.select();
});
Use the up and down arrows to scroll through cells in the list. When it hits top or bottom, it should scroll into view if the new cell is not already in view.
This fiddle example still works fine in IE10+ and Firefox, but in Chrome 39 (latest version), it will not scroll when you arrow into a new cell off the bottom or top. Also, it looks like the textboxes redraw off by a few pixels sometimes.
When a new cell (input) gets focus, we call this.select() to select any existing text. If we remove the call to select(), then Chrome 39 works fine again. But, users would like to see text selected.
The question is: Is there something I am doing that would cause this, or is it a bug in Chrome 39?
If it is a bug, does anyone know a workaround to select input text without breaking the native scrolling into view behavior? Any ideas would be appreciated.
Update:
It appears that even removing ALL JS code, leaving just a bunch of inputs in a scrolling div also fails (only on Chrome). You can only navigate with tab/shift-tab without JS, but scroll problem still occurs. Am I going crazy, or do other people see the same screwy scrolling when running this fiddle?
See Updated Fiddle for example.
The problem seems to occur, in my experience, from a parent container with position absolute/fixed with z-index value. This affects Chrome 39+
Try setting that parent container to have the following CSS declaration:
-webkit-backface-visibility: hidden;
Well, it looks like it is just a bug in Chrome 39. Hopefully, they will get it fixed before too long.
Luckily, Chrome is also one of the few browsers that supports the scrollIntoViewIfNeeded() method, so as a workaround I was able to do something like this in the focus event handler:
this.select();
if (typeof this.scrollIntoViewIfNeeded === "function")
this.scrollIntoViewIfNeeded(true);
So, that solves the immediate problem.
I have a problem with a news ticker in Firefox - the scrolling element becomes invisible when animating - and some weird behaviours are occurring:
When static, the element is displaying well, but when animating it is becoming invisible.
When mousing over the scrolling element it becomes visible, when mousing out it becomes invisible again.
When opening the "Inspector" window in Firefox, to look over the code, the element becomes visible. When closing the "Inspector" window, it becomes invisible.
Replicated the exact code in JSFiddle and the problem is not occurring when testing in Firefox.
I have looked over the code and I have made tests but I cannot find the source of this problem.
In all other browsers everything is working well, only in Firefox this weird behaviour is happening.
Edit:
It seems to be a local issue happening only on my end.
Removed links.
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);
});
Because there are a couple of skinned select boxes on my site, I am using dropkick.js, which essentially replaces the select boxes with interactive divs. If the list is larger than the max-height, the overflow-auto makes scrollbars appear. It works fine on Firefox, Chrome and Safari.
On Windows 8 + IE9 & IE10 a scrollbar appears, but when I click or try to drag it, the div hides!
> Link to the page
I have only found a slightly similar issue on a Bootstrap UI combobox but that script did not work for me, because dropkick.js does not use Bootstrap and adapting the script did not solve the problem.
> Link to similar bug
I was hoping it could be fixed with stopPropagation on the div but no luck on that either. Tried -ms-overflow-style:scrollbar but that does not change the behaviour.
Has anyone stumbled across a working fix for this in IE9+?
I had the same problem last week on one of my projects.
I solved it by changing the "click" event for closing the dropdown to "mousedown".
For some strange reason IE9+, on Windows 8, considers the scrollbar outside of the DOM element for click and mouseup events but for mousedown event it accepts the scrollbar as part of the DOM element.
By the way, I tried to reproduce the bug on your site but couldn't(Tested on IE10/Windows 8).
I have a page where necessary elements are repositioned over some extra html attributes.
For example:
<div class="contentplate" relativePosition="top-left" relx="1" rely="3" relw="14" relh="8" relFontSize="80"></div>
is repositioned by class 'contentplate'. It is positioned to a raster related on the actual windowsize. It's child elements are processed recursively to get the relative positioning also working inside this containers. All of this works as expected.
The trouble begins when using jQuery('parentcontainer').animate( {left:0},100 ) or something:
in some way repositioning the elements leads, jquery to animate only the parent element and not the childs.
the funny part is after te animation is done, the position of the childs is corrected somehow by jQuery but as told not animated.
All the elements are styled position:absolute, overflow:hidden
and no, the repsotion algorithm only runs if the window is resized, or after the page has been loaded once.
I have 3 Test for you if you are interested:
the site fully dynamically repositioning (animation is failing, except in firefox)
http://www.bourier.org/demos/jquery_animation_failure/test_2.html
a snapshot of a repositioned site without active repositioning (all browsers, all good)
http://www.bourier.org/demos/jquery_animation_failure/test.html
a fully dynamically repostioning site with a yellow grid you can see enabled
http://www.bourier.org/demos/jquery_animation_failure/test_3.html
a screenshot where you can see the dynamic page with grid enabled
thanks for your time
As it seems, it is a bug in the browser Engine correlated to usage of a canvas and CSS modifications of div's z-ordered above.
The canvas is there only for checking the grid features are correct e.g. debugging purposes.
I removed the canvas and everything is working now as expected.
There is something very wrong, can be shown here using the chrome developer tools:
The elements are detected in the correct position by the debugger, and mousepointer, but they are not displayed there. very odd this.
i don't want to digg deeper than this, but in my opinion the Firefox behaviour is correct and Chrome and Safari are doing something very wrong.
If i should post a issue report to chrome developers leave a comment and i will.