document scroll doesn't work in IE - javascript

Neither this script:
$(window).scroll(function() {
alert("works");
})
nor this:
$(document).scroll(function() {
alert("works");
})
works in IE 8 and earlier.
I don't know why, could somebody help?

Create jsfiddle and check it in browserstack:
IE8 - window scroll works
IE7 - window scroll works
Check what you don't have javascript errors on page.

Mainly three things you should see
1.If you have given style as
overflow:hidden
2.If you have given height in page percentage.
3.if you have given float:static.
Fix this issue your IE 8 problem will be solved.
Reason :
IE 8 is different than nything else for CBC check IE frist! To the topic, IE 8 hides (only scrolling bar) of scroll bar if you have overflow as hidden, secoundly if you have places hight as 100% IE 8 takes overflow as hidden (can say takes by its own!) n float is element who can go beyond page size if you have it as inherit or relative but static dose not increase dynamicly.
Hope this helps...

Related

scrollTop returning much lesser value for a div in firefox

Reference Link: http://old.crazyripples.com/?debug=1
So, I am using jQuery and the jQuery fullPage plugin. It helps me achieve frame by frame scrolling.
Now, for internal divs where the vertical height is greater than the window height I have used some functions where I simply check for the scrollbar position and stopPropagation to the plugin so that inner scrollbar scrolls without shifting the frame.
All works fine with chrome and since I built with chrome I used some calculations that I observed on chrome. But firefox is showing different results, especially with scrollTop.
I am aware of the fact that there can be a difference in height but if you see the logs in the reference link you will see, the height is almost the same(even if it isn't for you, its the scrollTop value that is an issue).
Here is the code that I am using to decide whether to stopPropagation or not.
$(document).on("keydown",function(e){
var story=$("#story"),
story_con=story.find(".container"),
story_top=story_con.scrollTop();
if(story.hasClass("active")){
// console.log(story_top,story_con.height(),story_con.innerHeight(),story_con.children("div").height(),story_con.children("div").innerHeight(),e.which);
console.log("Div ScrollTop: "+story_top, "Container Height: "+story_con.height(), "Container InnerHeeight: "+story_con.innerHeight(),"Conatiner Div Height: "+story_con.children("div").height());
//up arrow
if(story_top==0 && e.which==38){
console.log("prev frame")
}
//down arrow
//chrome 280+432 >= 676 i.e. 712>=676 true
//firefox 207+429 >= 676 i.e 636>=676 false
else if(story_top + story_con.height() >=story_con.children("div").height() && e.which==40){
console.log("next frame");
}
else{
story_con.focus();
console.log(story_con[0]);
console.log("stopped propagation");
e.stopImmediatePropagation();
}
return;
}
});
And this is how I am calling the plugin:
$('#main').fullpage({
sectionSelector:'.frame',
scrollingSpeed:800,
responsiveWidth:1025,
normalScrollElements: '#story, #startups, #services',
});
Replication:
Go to the reference link. Navigate to the second section(Our Story) by either scrolling, arrow keys or the menu. Now, only use arrow keys, the frame should scroll normally, but when the scroll completes, it should go to the next frame(does so in Chrome). See js logs for more details.
I would love it if anyone could help me in any way. I have been trying to debug this for sometime. Maybe I am focussing on the wrong issue? Any help will be appreciated.
P.S. I know the plugin offers a scrollOverflow option. That was inducing more issues than this approach.
Update: Since I wasn't able to find any solution so specific, I changed my approach of detecting if the frame scrollbar had reached its end. I used this:
//down arrow
else if(container[0].offsetHeight + container[0].scrollTop >= container[0].scrollHeight){
console.log("next frame");
}
*This is the start of my answer as I continue to debug to give you better details.
Currently using Firefox version 49.0.1 on window sizes smaller than 1280px your content inside your container classes are too tall.
Current proof:
In your divs, #story, #partners, and #services, if you where to give the div that is the direct child of div.container in each of the major sections a height: 200px all of your arrow down keypresses will work.
Edit 1
In magic.js line 111 is where your issue starts.
else if(story_top + story_con.height() >=story_con.children("div").height() && e.which==40){
The content within each of your containers, story_con.children("div").height(), is sometimes greater than story_top + story_con.height() so it does not go into the next page path that you desire.
Of course this all depends on the height of the window.
Your debug logging proving my point:
The Simple answer would be because Chrome and Firefox render pages differently. To understand why you get the differences in rendering have a look at this Explanation
I hope this clears it out.

outerHeight in Chrome giving wrong value, OK in IE and FireFox

In the jquery.smartWizard plugin, there is a function called fixHeight which adjusts the height of a wizard step. This is used when a step is first displayed or when revealing hidden divs within the step. It works fine in IE (at least in IE 11 on Win8.1) and in FireFox. But, in the latest version of Chrome (Version 40.0.2214.94 m) the outerHeight is a much smaller value than it should be, by over 100 pixels or more.
This is the function, out of the box:
SmartWizard.prototype.fixHeight = function(){
var height = 0;
var selStep = this.steps.eq(this.curStepIdx);
var stepContainer = _step(this, selStep);
stepContainer.children().each(function() {
if($(this).is(':visible')) {
height += $(this).outerHeight(true);
}
});
// These values (5 and 20) are experimentally chosen.
//stepContainer.height(height);
//this.elmStepContainer.height(height + 12);
stepContainer.animate({ "height": height - 12 }, 500);
this.elmStepContainer.animate({ "height": height }, 500);
alert(window.outerHeight);
}
I modify the final steps to add the animation. With or without Chrome fails.
EDIT:
Here is a fiddle that demonstrates the difference between IE and Chrome. Click member, then click non-member. You will see that second set of values is different in each browser.
http://jsfiddle.net/xjk8m8b1/
EDIT2:
Here is another fiddle that shows both browsers get the same values for height until you try and calculate the visible elements. Then Chrome is way off.
http://jsfiddle.net/xjk8m8b1/2/
While not the best solution, I did figure out the issue. Firefox and IE are both adding up the height of everything in the div, include break tags and anything that creates vertical space. Chrome, in my opinion is broken, and not adding up these extra elements! It is not returning a true value for consumed vertical space.
My workaround is to wrap the contents of the div inside another dummy div. This way jquery looks at the height of that first child div and correctly returns the height.
I have the same problem, a ScrollBar is in the middle, the StepContainer never fixes the height.
Then I change this line in jquery.smartwizard.js:
$this.elmStepContainer.height(_step($this, selStep).outerHeight());
To this:
$this.elmStepContainer.height(_step($this, selStep).outerHeight() +20);
20 is enough for me, and my problem is gone.

window width in JS doesn't match max-width CSS

It looks like in chrome:
$(window).width()
is not matching the CSS3 media queries, when there are scroll bars. Without scrollbars it matches fine.
Does anyone know a good work around?
Here is the example: http://codepen.io/krismeister/pen/LmJFt/
Make your browser, about 600px wide then drag across teh 550px width. Then toggle the scrollbars. I'm on chrome Version 33.0.1750.152
I found this workaround on a similar stack thread:
CSS media queries and JavaScript window width do not match
Got a jsFiddle to work for you. http://jsfiddle.net/j839b/
Using this
function recordWidth(){
var w=window,
d=document,
e=d.documentElement,
g=d.getElementsByTagName('body')[0],
x=w.innerWidth||e.clientWidth||g.clientWidth,
y=w.innerHeight||e.clientHeight||g.clientHeight;
$('#last-width').text(x);
}
From http://andylangton.co.uk/blog/development/get-viewport-size-width-and-height-javascript
Im on chrome and seems to change with me:
No scrolls: last recorded width - win:1920, doc:1920, body:1904
With scrolls: last recorded width - win:1905, doc:1905, body:1889

jQuery Waypoints Context not Working in Safari or Chrome

I have a web application that sizes the html and body elements at 100% width and height and puts overflow: scroll on body to create full screen slide elements. I'm using jQuery Waypoints for sticky navigation and to determine which slide is currently visible.
Since the body element is technically the one scrolling, I set context: body. This works as expected in Firefox, but the waypoints won't fire in Chrome or Safari.
I can get the waypoints to fire by manually calling $.waypoints('refresh'); after scrolling to a point where they should have fired, but calling this after every scroll event seems like a very cumbersome solution.
$('body').on('scroll', function(){$.waypoints('refresh');}) —it works, but sure isn't pretty.
I'm assuming this has something to do with how each browser interprets the DOM, but is there a known reason why Chrome and Safari wouldn't play nicely with waypoints in scrollable elements?
I'm looking for one of two things, either what I've done backwards in my use of waypoints, or what the underlying issue is so I can fix it and make waypoints work properly for everyone.
For the record (and before anyone asks), I've done my research and this isn't an issue with fixed elements.
Edit: finally got a CodePen built for this. Take a look.
Remove overflow:hidden from html. Unfortunately looks like this is required - I hope it doesn't break your layout.
Next, you'll need #nav.stuck { position: fixed; } instead of absolute for a sticky header.
Use this js:
$('#nav').waypoint(function(direction) {
if (direction == 'down') {
$(this).addClass('stuck');
} if (direction == 'up') {
$(this).removeClass('stuck');
};
});
That works for me - see http://codepen.io/anon/pen/GgsdH
How about this?
$(window).load(function() {
$('#myheader').waypoint('sticky');
});
… instead of this:
$(document).ready(function(){
$('#myheader').waypoint('sticky');
});
This is of course stupid if you have a huge amount of images to load, but this solution saved my day.
Try min-height: 100% on body and html instead of height, if appropriate for your layout.
Delete overflows and heights in html and body, also context is not needed. Worked for me.

jQuery animate scrolltop on Opera bug

Has anyone tried using
$(“html, body”).animate({scrollTop:0}, 'slow');
on Opera browser?
It does a weird effect especially if you scroll on a long page, it seems like the page go first to the top and then it scroll down to the right point. It is a weird disturbing effect...
Is there any workaround to fix it? thanks
The attribute was not defined properly in the past. It was introduced by IE, I think, then reverse engineered to be implemented by different user agents. It has been since described in CSSOM (still a working draft). As of today, there is still a bug indeed in Opera which is being in the process to be fixed.
## Possible hack.
A solution will be
$(window.opera?'html':'html, body').animate({
scrollTop:0}, 'slow'
);
Be careful because if Opera fixes it at a point, the code is likely to behave strangely.
Why?
In Firefox and IE quirks mode, you have to set the property on the "body" to make the page scroll, while it is ignored if you set it on the "html".
In Firefox and IE standards mode, you have to set the property on the "html" to make the page scroll, while it is ignored if you set it on the "body".
In Safari and Chrome, in either mode, you have to set the property on the "body" to make the page scroll, while it is ignored if you set it on the "html".
Since the page is in standards mode, they have to set it on both the "html" and "body, or it won't work in Safari/Chrome.
Now here's the bad news; in Opera, when you read the scrollTop of the body it is correctly 0, since the body is not scrollable within the document. But Opera will scroll the viewport if you set the scrolling offset on either the "html" or "body". As a result, the animation sets two properties, once for the "html" and once for the "body". The first starts at the right place, while the second starts at 0, causing the flicker and odd scroll position.
Better solution not involving user agent sniffing
From http://w3fools.com/js/script.js
// find out what the hell to scroll ( html or body )
// its like we can already tell - spooky
if ( $docEl.scrollTop() ) {
$scrollable = $docEl;
} else {
var bodyST = $body.scrollTop();
// if scrolling the body doesn't do anything
if ( $body.scrollTop( bodyST + 1 ).scrollTop() == bodyST) {
$scrollable = $docEl;
} else {
// we actually scrolled, so, er, undo it
$body.scrollTop( bodyST - 1 );
}
}
This http://www.zachstronaut.com/posts/2009/01/18/jquery-smooth-scroll-bugs.html#opera might be a better solution without using any Opera specific functions and accounting for quirks mode.
$("body:not(:animated)").animate({ scrollTop: destination}, 500 );
return false;
works for me, in opera as well.
EDIT: does not work in firefox though
I've had this problem, too. This is what I use and it works. It's not browser sniffing, but it's not particularly nice code, to me. It works tho, for now.
Calling scrollTop on html element in Opera 11 / IE 8 / FF 3.6 returns a number larger than zero
Calling scrollTop on html element in Chrome 10 / Flock 3.5 / Safari 5 (for Windows) returns 0
So just test that:
If the browser is Opera, you test for a number larger than 0 on scrollTop, and call scrollTop on only html, a la
var html = document.getElementsByTagName('html')[0];
var body = document.getElementsByTagName('body')[0];
$(html).animate({scrollTop:0+'px'},{'duration':1000,'easing':'swing'});
If the browser is Chrome, or Flock or Safari than scrollTop will return 0 and you test for that, acting accordingly:
$(html,body).animate({scrollTop:0+'px'},{'duration':1000,'easing':'swing'});
So, you'll set the effect on html for standards mode FF and IE (quirks should be covered, too. Ugh), and body for Chrome and Safari.
In Opera, which attempts to scroll both html and body, thus leading to mass freakishness, scrollTop returns a number greater than 0, so you call only html and you don't get the flickery nonsense.
So you can safely use both html and body when necessary, or just html when the browser is Opera.
And don't forget yer preventDefault() or that'll be another weird flicker you'll have to worry about. ;)
Hey, I'm no JS ninja, but I try hard and this works for me, and I don't have time right now to investigate it as much as I'd like, so I thought I'd post this here and help. If I'm wrong I'll hold up my hands and say it. ;) So feedback, please. :D
Tom.
Yep!
I had a problem with action of animate({scrollTop: }) function called in click() function.
The best way is http://www.zachstronaut.com/posts/2009/01/18/jquery-smooth-scroll-bugs.html#opera, which was written here by Divya Manian.
One need to use event.preventDefault() before calling scroll function or animate function to end click event before start scroll event.
Something like this:
$(<clicked_element>).click(function(event){
event.preventDefault();
$('html, body').animate({scrollTop: <value>}, 600);
});
EDIT: It's important to apply scroll method to $('html, body') elements

Categories

Resources