I know how to get the scrollTop of a page, I use this simple JS function (code copied around):
function GetScrolledTop()
{
//I never work in IE quirkmode, I always use DOCTYPE as 1st line, so I don't need to test for document.body.scrollTop
return self['pageYOffset'] || document.documentElement.scrollTop;
}
This works and my problem is the following: I tried to add it in the page onload event
<body onload="alert(GetScrolledTop());">
On page load I get ZERO (which make sense), but the problem is that I get ZERO even if I scroll the page and then reload it without touching the scrollbar.
It seems like the browser does:
loads page
calls my GetScrolledTop() (so obviously shows ZERO)
then scrolls the page to where it was before.
Do you know how to get the scolledTop after the step 3?
I mean how to get the scrolledTop AFTER the browser scrolled the page?
(maybe without using a timer)
Probably not without using a timer. But you might be able to use a timer with a 0ms delay, which would execute the function when the thread becomes idle, whilst still appearing to be instant:
<body onload="window.setTimeout(function () { alert(GetScrolledTop()); } , 0);">
EDIT - Thought it might also be worth mentioning that most browsers support the onscroll event, which should fire after the window scrolls.
Related
I have observed that after a refresh, by pressing F5 or even some location.reload();, the browser forces a scroll to the last position it was before the refresh.
The thing is, we track the user's progress across the page, and this "automatic" scroll fires all the checkpoints we have placed all the way to this last position before the refresh.
We are wondering whether is it possible to differ this "automatic" scroll from a scroll made by the user.
For instance, we have lots of:
$(window).scroll(function() {
var windowMax = $(window).scrollTop()+$(window).innerHeight()/2;
if (windowMax > .....)
});
Is there a way to differentiate this two sorts of scrolls?
Edit
Please, see that I don't want to prevent the automatic scroll, I want to differ it.
You can add a ready event listener and immediately check the .scrollTop() after it has been loaded.
var isScrolledAfterRefresh;
$(function() {
isScrolledAfterRefresh = $(window).scrollTop() > 0;
});
You do need to be sure that the rest of your code is executed after the ready event is fired.
This is something embedded in the users browsers. One way to counter it I suppose is to not have scrolling enabled on body or HTML, and have a custom scroll inside an element that is not on the top layer
You could also deffer recording of the scrolling until the page has fulling been rendered and the document completely loaded.
You could use the following to do stuff when the document is ready :
$(document).ready(function(){
// do stuff here
});
Hello I am trying to create a refresh script to refresh a page on incomming messages,updated posts,ect. Why is x,y not executed useing ex: 1? I have seen a few different methods of reloading a page and keeping scroll position but they seem overkill. I think I would like to use ex: 2, is there any logical way to clear the server side variables using reload() or should I go another route for something like this?
function Refresh()
{
var x = window.pageXOffset;
var y = window.pageYOffset;
//ex 1:this works but doesnt keep scroll position
//window.location = window.location.href;
//ex 2: this works and retains x,y but doesnt refresh $_POST $_GET server side variables
window.location.reload();
window.location.scrollTo(x,y);
}
//for testing only
setInterval('Refresh()', 5000);
scrollTo is not executed because that line is never reached and also wrong. The moment you trigger a page load, script execution stops. Furthermore, window.location refers to the address-bar, basically, and scrollTo does not make sense here. Better would be window.scrollTo, but never mind:
A reload preserves scroll position (in most browsers) and $_GET variables, however browsers usually want user-confirmation to reload a POST-request. You probably do not want that behaviour.
The least "overkill" way to make the browser scroll to new content is using hash-tags, assuming you are in control of the updated content.
Just append something like #newcontent to your URL and set the id of your new content:
<div id="newcontent">Cool new post...
Browsers will auto-scroll to a fragment identifier.
I have a page where I show a throbber when I navigate away from the page. Like <a onclick="throbber.show()"> on every link. When I now navigate back in Firefox, the throbber is still shown.
Is there any javascript event that is fired to the arriving webpage when I click back? Or one that is fired just when the webpage is changed to the new one? Or can I make my throbber more intelligent?
Thanks for any input!
put this in your html:
<form name="_browser"><input id="checker" value="1" type="hidden"></form>
and also this javascript:
function cacheCheck()
{
var checker = document.getElementById("checker");
if (checker.value == 2) return true;
checker.value = 2;
checker.defaultValue = 2;
return false;
}
function cacheReload()
{
if (cacheCheck()) location.reload(true);
}
and then call cacheReload when your page loads:
<body onload="cacheReload()">
Dldnh's answer inpired me to do some tests. I suspected that the body.onload() event would be called when going back and forth. So I created a simple testpage and found out that this is true in Firefox 10, IE7, IE 8, IE 9 and Chrome 17. Also jQuery(document).ready() will be called.
The very simple solution for hidind the throbber would therefore be either using
<body onload="hideThrobber()">
or using jQuery ready
jQuery(document).ready(function () {
hideThrobber();
};
to hide the throbber then. I implemented this and it seems to work fine on my page. Would be great if somebody with a similar problem could confirm this.
I also found this interesting Stackoverflow question. While it is a little outdated, the point that calling javascript on navigation back and forth slowing down the page is still true. But I would guess that todays JS-Engines are fast enough so this is not a real issue anymore.
If you can't turn off the throbber from the page you navigate to, there are a few things you can do. The trick is that the page will be left active, so you can start up some things before you leave, in the onclick. They aren't perfect though.
Start a timer. The timer will be running when you return to the page, so the timeout routine will be called, and you can switch the throbber off there.
Problem: if you set the timer interval too small, the timeout routine will be called before the user has actually left the page, and the throbber will stop. Or if you set the interval too large, it will take a while before the timeout routine kicks in after they have returned.
Add an event listener to the body that responds to the mousemove event, so that as soon as the user moves the mouse, the routine that turnes off the throbber will be called.
Problem: if the user clicks the browser's Back button, the mouse will be outside the window when the page is redisplayed, so the throbber will remain visible until the user moves the mouse into the window.
So, take your pick. Or do both. Just remember to clean up afterwards - stop the timer, remove the event listener.
I've got two JS functions, one that is adding options to a select box
function addOption(selectId, text, value) {
var selectbox = document.getElementById(selectId);
var optNew = document.createElement('option');
optNew.text = text;
optNew.value = value;
try {
selectbox.add(optNew, null); //page position resets after this
}
catch(ex) {
selectbox.add(optNew);
}
}
and another that is doing a document.getElementById(formId).appendChild(newHiddenInput) in a similarly simple function.
They both work, elements are added as expected. However, upon calling either of them, the page resets its scroll position to the top of the page in both IE6 and FF. There is no postback, this is purely clientside manipulation. I've set breakpoints in Firebug, and it occurs immediately after the element.appendChild or select.add gets executed. I know I can use JS to manually set a scroll position, but I didn't think it was necessary when the page isn't being re-rendered.
I'm no expert with JS or the DOM, so I may very well be missing something, but I've looked here and ran through their examples with the Try it Here options and I can't replicate the problem, indicating the codebase I'm working with is the culprit.
Any ideas why the scroll position is being reset? jQuery is available to me as well, if it provides a better alternative.
If the functions are being called from a link you might have an internal anchor in your link:
http://www.website.com/page.html#
This is causing said behavior. The default behavior is that if an anchor does not exist, the page scroll position jumps to the top (scrollTop = 0).
If this happens on every function call regardless of the source, then this can be crossed off the list.
What is activating the event?
If it's an anchor then on the click event you need to "return false;" after the call to your jQuery/Ajax/jScript code.
If it's a button you may need to do the same.
I had this issue yesterday and this was the resolution.
So My link
I have a page that on a certain action makes an iframe visible and fills the iframe with some HTML (say for example a multi-select box and an ok button).
The OK button on the iframe has the onClick method defined kinda like this:
onClick="parent.hideIFrame();parent.processMultiSelectBox();"
When User clicks OK on the iframe (presumably after playing with the multi-select box), I'd like the iFrame to disappear immediately and then the selected values in the multi-select box can be processed. But this is not what's happening. The iFrame remains visible during the time the other function runs and disappears only after the second function finishes.
The hideIFrame function is pretty straightforward:
function hideIFrame() {
frmObj = document.all.iFrameID;
if(frmObj) {
frmObj.style.visibility = "hidden";
}
}
I've paraphrased the above function for clarity (removed some indicator variable assignments etc.)
The second function actually loops on all the options in the multi-select object and does stuff with it. This takes about a half a second and only after that is done, does my iFrame disappear. It is a little bothersome to see it linger for half a second when I click ok.
My question is whether there is some way I can make the darn thing disappear faster. Speaking in "classical C" lingo, is there a "flush" for the change in visibility to happen immediately?
I did notice that if I put an "alert" as the first line in my second function, the iframe disappears immediately but now it is the OK on the alert box that lingers for the time it takes the second function to finish.
Thanks.
EDIT: Based on DDaviesBrackett's answer, this is what I ended up doing:
The onclick in the iframe changed to:
onClick="parent.hideAndProcessMultiSelectBox(parm1, parm2);"
The hideAndProcessMultiSelectBox function was defined as:
function hideAndProcessMultiSelectBox( parm1, parm2 ) {
hideIFrame();
setTimeout( function() { processMultiSelectBox( parm1, parm2 ); }, 0 );
}
Voila.. no delay..
You've gotten to the root of your problem already; document reflow doesn't happen until the current JS thread is done (so as not to repaint lots of times during JS execution). You need to return control to the browser before doing your expensive processing.
The simplest way to achieve that, though it doesn't make for obvious code in the slightest, is to call processMultiSelectBox in a setTimeout with a delay of 0:
onClick="parent.hideIFrame();parent.setTimeout(parent.processMultiSelectBox,0);"
If you need to pass parameters to the thing you're setting a timeout on, you have two options: set a timeout on a string that evals to Javascript (bad, bad, very bad, horrible) or define an anonymous function that calls the one you're interested in:
onClick="parent.hideIFrame();parent.setTimeout(function(){parent.processMultiSelectBox(foo, bar, 'baz');},0);"
RSolberg's response may also help, though there's a difference between visibility:hidden and display:none.