I've tried using both scrollTo(y,x) and scrollTop(x-pos), values in the parenthesis being the offset.top values of individual DOM elements. These seem to work in all browsers initially, however when refreshing Chrome to resend the form submission, the page jumps to where it should be for a split second then jumps back to the top. This occurs when I scroll back to the top of the page prior to refreshing the page. Does Chrome save some sort of session variable or track the page position on refresh such that when refresh is clicked, the page focuses on the portion of the screen last viewed? And if so, is there a way to prevent such a reaction from Chrome? I've tried adding a setTimeout in the hopes that my scrolltop or scrollto (As stated, I tried both) wait until Chrome has reacted to the page load, but with no change to the result.
if ($('.register_box').length > 0) {
if ($('.register_box').find('.error').length > 0) {
var regbox = $('.register_box').offset();
$('body').scrollTop(regbox.top);
}
}
I've tried 'body', 'html', a selector wrapper, window, screen, and a combination of these - no change. I've also alerted the value for regbox.top and consistently get the value of 699, so I know it's passing the correct value. Do I need to stop propagation or prevent default, and if so, where? Firefox and IE both respond correctly. Chrome, on both Mac and PC, do not.
Try $('html, body'). See jsfiddle here.
Related
I added some page transitions to my site. Now whenever someone clicks on the browser back button, that redirects him to his previous site, his scroll position on that page gets restored automatically. If the user has scrolled down on the previous page, this behavior leads to an ugly page jump in the current window less than a second before it fades out.
1) Am I able to delay this default browser behavior?
2) If 1 is not possible, am I able to disable the default behavior and store & restore scroll positions manually instead?
Although it is experimental, you can try adjusting the History scrollRestoration from "auto" to "manual".
There are a few polyfills out there to help with cross-browser compatability too.
if ('scrollRestoration' in history) {
// Back off, browser, I got this...
history.scrollRestoration = 'manual';
}
I have a site in which I'm implementing parallax using skrollr.js.
In that site I'm also integrating Flash objects created by Storyline, in iframes.
My problems is that after the user interacts with the Storyline in the iframe, when he tries to continue scrolling to the rest of the content, sometimes the page gets stuck and stops scrolling.
This happens only in Firefox (it doesn't happen in Chrome, and surprisingly enough - not in IE11 either).
The only way to "unstick" the scroll is by the user clicking the browser window again. Of course, that's not intuitive to the user, so I'm trying to find a way to emulate that click programmatically.
I thought that maybe the focus gets lost and the mouse click returns it, so I tried returning the focus to the body programmatically, but that doesn't help:
setInterval( function () {
if ( document.activeElement.tagName.toLowerCase() === "iframe" ) {
document.activeElement.blur();
}
}, 1000 );
In the end, this problem got solved by changing the wmode parameter from window to transparent.
The way to do that is as follows:
I can't find where to change wmode to transparent in Storyline, but I found how to change it in the generated files :
In the root of the generated directory, find the story.html file.
Go to line 134, where the g_strWMode parameter is defined.
Change its value from window to transparent.
That's it!
I have a form within a loop on our site and when someone submits the form then a query string is added to the url something like "?updated=111". Then my JQuery script checks the url for the number and scrolls to that div once the form is submitted and page reloads.
This script is working fine in Firefox but doesn't work as well in Chrome or Safari. For example, say on my page I have 25 posts, and each posts has its form. Lets say I submit the form on post number 25 (the last one) then when the page reloads on chrome the window scrolls but not all the way to #div25 sometimes it works ( for like 1 -5) other times it will only scroll to half the window.
Is there a fail safe way to make sure the window will scroll to that div after the page refreshes? Again, the below does work in Firefox but only partially works in Chrome and Safari.
<script>
jQuery(document).ready(function($) {
if(window.location.href.indexOf("?updated=") > -1) {
var postID = window.location.href.match(/\d+$/);
$('html, body').animate({
scrollTop: $('#post-'+postID).offset().top
}, 'fast');
}
});
</script>
Also side note, not sure if this helps but once the form is submitted if I hit refresh on the page then it scrolls to the correct location.. Not sure if I should add a delay or speed up the animation to make this work cross browser like it does in FF?
Try putting the ".animate()" method inside a timeout of 2seconds. Does the problem go away? If it does, then its timing issue. Most likely thats because the browser is not ready to scroll to the location that you ask it to scroll to.
In this situation, you'd rather go with a timeout of 0 than a 2 sec. A 0 timeout just schedules the scroll for next cycle whenever the browser is free.
HTH!
I use:
var el = document.getElementById("centd");
el.scrollIntoView(true);
to scroll to specific position. In every browser it works fine, but in Chrome when the page is loaded it scrolls to that point, but after a second or two (when the page is finished loading) it scrolls back to start.
Make sure all your JavaScript code is run after your page completes loading:
document.addEventListener('DOMContentLoaded', function() {
// your code here
}, false);
Or if you're using jQuery:
$(document).ready(function(){
// your code
});
This will make sure that your code runs the way you intend.
I feel like it's supposed to be a feature and not a bug (but cannot find evidence to support this theory): it works fine the first time the page loads / in a new tab, but as soon as the user scrolled, that scroll-position overrides any scrollTo or scrollIntoView commands (in this briefly flashing fashion you described, and that I am currently trying to make sense of) – even if you wait for the document to be ready.
Other browsers don't share this behavior, in my experience.
Suppose I have a link, which would fade out the entire page when link is clicked. The reason I fade out the page is because a next page is about to load, but it is not loaded yet. I can use pointer-events: none which will disable any mouse events until the next page is loaded.
Suppose it was done with the keyboard, I could use the following to prevent double-enter, or to cleanly disable all elements within, for example tab-enter would be disabled this way as well.
parent.onkeydown = fals
parent.onkeyup = fals
parent.onkeypress = fals
function fals() {return false}
This works well for short loads, but if it takes a long time to load, the user may notice the following difficulties.
Cannot tab away from the a tag.
Cannot use several of the keyboard shortcuts which would control the browser.
Able to tab into the disabled area from the address bar.
Is there a modern and slick way to prevent these 3 problems, other than setting an onfocus=blur for all of the child elements? I do not care about IE today.
I think the commonly accepted way of dealing with things like what you're talking about is to use Modal's, which is to say when they click that link, you pop up a box that says 'Processing' or something like that, and you create a fullscreen div with a z-index above everything else so the user can't click / interact with anything else on the screen until you're done doing whatever it is you are doing.
See http://twitter.github.com/bootstrap/javascript.html#modals for an example of what i'm talking about.