I met a issue when use an anchor with hash to navigate to a Microsoft KB, this link goto leve2
go to a wrong place in IE but in other browser works fine. I guess this is because of page content changed after page loaded, dose anyone met this issue before?
May be this is a window.load and hash parse sequence problem. When other browsers execute onload event handler first and then set hash position while IE does in opposite way.
Note that if you enter in IE's address bar the again, it scrolls to correct position.
Related
When a page loads an iframe with a url ending in a #, the parent page scrolls so that the iframe's body is at the top of the browser window.
Demo: http://jsfiddle.net/dTQEE/1/
If the URL ends in #, e.g. http://foo.com#, the browser assumes you want to go to the top of the page.
How do you prevent the parent window from scrolling when an iframe with a hash fragment is loaded?
Problem happens in Chrome, not sure if it's an issue in other browsers.
Right now the best solution I have is to use el.addEventListener('scroll', ...) to reset the scrollTop to 0 if it's not already 0. This works, but the scroll down and the scroll up are both very noticeable.
Not sure this is possible, but you should try to tap into window.onhashchange event and prevent default. If not, you'll have to strip the hash if it's not followed by anything.
I know this is an old question, but I came across it in my search for the same problem. I just came up with a solution that works wonderfully for me in Chrome.
<a href="dummylink.html" onclick="someFunction(); return false;">
The href link is used for the status bar, but because of the return false; at the end, it doesn't actually go anywhere. Then, you just do your redirection (in my case it was a document.formName.submit();) inside your someFunction();. Come to think of it though, you could do everything inline, but that doesn't really seem good form unless you only have one thing to do.
Note: If your someFunction(); has return false; at the end, that will not be sufficient to prevent the jumping.
This already works well in FireFox, IE and Opera, but in Chrome and Safari this is a problem. I have an onClick event function on links that leaves the page. These functions send requests to various tracking services to record the exit link.
I have tested this by removing the href attribute in the link. When it's removed, the link is tracked. When the link is active (and leads away from the page) the link is not tracked. This is only the case in Chrome and Safari.
I was hoping there was some non-extreme way of forcing the browser to finish the script before leaving the page. (By extreme I mean f.inst. removing the href attribute using javascript and manually redirecting the browser after tracking is complete)
jQuery is already loaded in this project, so it'd be great if it had a solution.
Thanks for any and all advice
Google analytics _trackPageView does not offer a callback so you have no easy way to get a success callback, then proceed to your next page. There is a callback though on _trackEvent, and that's triggered each time some GA event occurs. You can try this and listen for it like so (make sure to put your href's back into your links - this depends on that being there, plus you'll get graceful degradation):
$(".myLinkClass").click(function(e){
e.preventDefault();
var link = $(this).attr('href');
pageTracker._trackPageview('/outbound/'+link);
if (pageTracker._trackEvent("Outbound", "URL", link)) {
window.location = link;
}
});
So basically I have
Link
And return false is there so that it wont' scroll up when you click on it. This works in IE and Firefox, but in chrome it still scrolls up nonetheless...
How do you prevent this from happening in Chrome?
Thanks in advance
There is no spoon
-The Matrix
Use: Link
Link
Don't have a link that points to the top of the page (which is what the URI # means), build on stuff that works.
That said, the return false should prevent the link from being followed, so long as JavaScript is active and error free. Since a link to the top of the page is undesired and a script that does nothing is pretty useless — I'd guess you have some other JS before the return statement that is erroring so the return is never reached.
you probably use href="#" to enable onclick functionality on <a> tag.
you can disable the href with href="void(0)" and you won't get the side effect of scroll to top on chrome
To prevent the default scrolling of a page I'm adding an event listener for "touchstart" events on the body and calling event.preventDefault() This works fine but I now can't access the debug console as it requires a page drag? Has anyone else had this problem and come up with a work around?
Hmm, interesting. Perhaps you can limit the scope of the bind to a less-encompassing region of the page, let's say an 'inner div' on the page, but not an 'outer div'? Then, perhaps you can leave yourself a small amount of margin between them for you to invoke the console?
i would suggest adding a parameter to the url by which you can reactivate scrolling
So I'm creating some HTML using javascript based on where the user clicks on the page. On page load the script replaces an empty div with a ul and some data. The user clicks on that data to receive more and so on. Now when the user navigates off the page and then hits the back button to go back to the page, IE displays a blank page with the replaced divs, in all other browsers, FF, Opera, Safari, the page either reloads to the initial ul or goes back to the last state with the dynamic data in it.
Anyone have an idea as to what might be happening here? Any help is appreciated.
It sounds like you need to manage the history and state of your page. Check our Brad Neuberg's Really Simple History.
The behaviour of onload events when navigating backwards and forwards is not standard cross browser. As a general rule, I have found that when you click back, onload events tend not to work as the browser is loading it from cache rather than re-requesting the page. What you can try is using the dom ready event rather than window load.
Trull's answer is along the right lines. Opera and later Firefox(>1.5) do not consider loading a page from the cache as requiring to trigger an onload event as the complete DOM state is also cached.
This is trivial to standardise across browsers, as Opera and Firefox do not exhibit this behaviour if you define a window.onunload event. See http://developer.mozilla.org/en/Using_Firefox_1.5_caching