I am developing, just for fun, a jQuery plugin that reveals elements from a "stack" as you scroll down the page.
Github repo is here - https://github.com/JayBizzle/Reveal
Demo is here - http://jaybizzle.github.io/Reveal/
Everything works great in Chrome, but when testing in Safari I am seeing some weird rendering issues.
If you view the demo in Safari and scroll down fairly quickly, you will notice white gaps appearing between the coloured DIVs.
Even stranger is, if you then inspect one of the out of position DIVs, the inspector highlights the DIV in the correct position. Also, if whilst your in the inspector, you change one of the elements CSS attributes, like adding a border, the page gets redrawn and the element appears in the correct position.
Anyone got any ideas if this is a Safari bug, or something i can overcome with some little known CSS?
I had a similar issue.
My workaround was giving position static first and then relative with a bit of delay.
$(elem).css('position', 'static');
setTimeout(function() {
$(elem).css('position', 'relative');
}, 1);
Related
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);
});
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.
In my web application I frequently have sections that need to be collapsed/expanded. I do this with jQuery using the slideDown() and slideUp() methods. They work great. However, in Firefox, if I am scrolled all the way to the bottom of the screen and I collapse a div the screen stutters and flashes as the div disappears and the page is automatically resized by the loss of the element.
Has anyone run into this problem before? I've been working around it by setting a min-height with a generous amount of space for any section that will be collapsible but this seems like an unnecessary solution. Chrome doesn't have this problem and, amazingly, neither does Internet Explorer, both of which smoothly resize the page without any sort of stutter or flashing.
I'm using Firefox 3.6 on Ubuntu and I've experienced this problem on earlier versions as well. I have not tested on Firefox 4.
I have ran into this problem before and yes. I have worked around this by setting a mini-height or consider not using a slide effect.
I'm having a problem related to WebKit:
http://demo.frojd.se/webkit/index.html
When you click "Menu item 1" it shows it's children.
This renders fine in Firefox 3.5, IE8 and in Opera 10.
In WebKit-browsers (Safari 4 and Chrome 3) it doesn't.
However, if I preset all the different classes and css-settings in the
html, it renders correctly (without the javascript click events). I've got an URL to show you, but can't since this is my first post.
Any ideas on why this might be?
Cheers,
Robin.
I really haven't looked at the code closely, but something to look at in this situation is the padding or margin set on the menu item divs. In Safari, those are not taken into account with respect to width, so they may make the div or contents of the div expand wider than you expect, and that would cause the next element to be pushed to somewhere you don't expect it.
Not sure if that'll help, but it's some place you can look if you're still stuck.
Edit: After looking at the source using Web Inspector, it seems the divs with class = 'parentHook' are not wide enough after getting clicked on. After getting clicked on the class changes to 'parentContainer', which sets 'margin-left:-18px; margin-top:-15px;', and that seems to throw off the width of that div. In Web Inspector I changed the width of that div to 150px, and it worked as expected.
A true and ugly hack- but hey it works.
try hiding and showing on the click of the <li>
for a simple test: try this in console
$('#nav li:first').hide(50).show(50)