Develop Reference

Window is in random offsets on page refresh

I'm using GSAP animations in a project and I keep running into this bug where upon page refresh the window will sometimes be in random places. When this happens I just type in window.pageXOffset to see where it's at. This sometimes happens with the Y axis as well. I'm using Chrome, but I've tested it out on Safari and it hasn't happened but it's a totally random bug. It usually will happen when my inspector is out and I've been clicking around A LOT! Clicking the 'empty cache and hard reload' button has fixed it every time. This is a wordpress project too, so I'm not sure when the scripts get loaded if that matters. Anyone know what's going on???

Android keyboard hide text inputs

I have an application using jQuery Mobile.
When testing on Chrome (on Android), when the keyboard is opened, some inputs located at the bottom of the page are automatically moved to the top. That the behavior I expect.
When I add this website into the Home Screen of my android, this behavior does not work, and all text inputs are hidden by the keyboard.
I have also remarked that when I open again the same application on Chrome, and after retry the Webview-based app, everything is now OK. The inputs are not hidden anymore.
Do you already seen this kind of error ?
Thanks by advance

I created a demo for you, as an alternative
I had to append a blank box to create some space at the bottom and then move the input up to the header when you focus on the input because its at the bottom so no scroll space.
Demo
https://jsfiddle.net/fyom081o/
Code
$(document).on("focus", "#text-basic", function(event){
var boxheight = $(window).height() - 40;
$("#mycontntent").append("<div id='blank' style='height:"+boxheight+"px;'"+"></div>");
$('html, body').animate({scrollTop: $('#text-basic').offset().top - 100}, 500);
});
$(document).on("focusout", "#text-basic", function(event){
$('#blank').remove();
});

Please see the answer from when I raised this same question...
Jquery Mobile 1.4.5 virtual keyboard in the device hides the form inputs at the bottom of the page
I opened an issue with JQM and this is the response I got. Turns out it's a Chrome fullscreen browser bug, nothing to do with JQM...
The only way i could think to attempt to work around this would be something like http://jsbin.com/kagidi/9/edit?html,css,output which fixes the issue on chrome homescreen however this is not really a complete fix it has a few issues that cant really be solved.
There is no way to know the keyboard size, and there for how much height to add to the body, on a particular device even more so when you keep in mind custom keyboards.
It requires a lot of userAgent sniffing to make it work properly
Because of these issues this is not really something we would add to the library i don't think. However this may solve your issue

Safari browser crashes, when unfocus and focus again tab with jquery code website

I create simple image slider, using jQuery. Tested on all browers. All works fine, but not in WinXP Safari. When i open another tab and load other website, and then focus again on my jQuery slider website tab - Safari crashes. Its happend only when my slider website actually animate images using fadeIn effect. When i try to switch tabs on my site, Safari crashes. I find what causes that, but not find an solution to the problem. Problem is probably with window resize and functions defines of dimensions of images and DIVs. And/or maybe setInterval function. I find many websites with different javascript and jQuery scripts with the same problem and no solutions (i.e. http://www.jssor.com/demos/banner-slider.html).

I find solution. Problem disappeared when i start script from:
$(window).focusout(function() {
if (navigator.userAgent.indexOf("Safari") > -1) {
location.reload();
}
});
I hope, that will help in some other problems with Safari.

Delay in hiding mobile address bar

I have a problem that's driving me nuts - I've found one other question about it, but no conrete solution.
I'm using the following to hide the URL bar on my mobile site:
window.addEventListener("load",function() {
setTimeout(function(){
window.scrollTo(0, 0);
}, 0);
});
This works fine, but there is just a very large gap between when the content jumps to the top, and when the actual URL bar slides up. Has anyone else run into this?
Here's the other question: Jquery mobile - Delay auto hiding address bar
This question points to iOS6's new 'Reader' button as the culprit; is there any forseeable way around it? Hiding Address Bar in Mobile Safari With Reader Button Visible
FYI, unlike the similar question I posted, I'm not using jQuery mobile, just plain old jQuery 1.8.

It might be that you have images or you are using scripts form CDNS that take a while to load, you might try loading the page in a browser and checking with the timeline tab to see if anything is taking a long time to load.
Another idea, the issue might be the the size of your screen is not initially long enough to allow for the scroll? So its possible that it can't scroll till you run additional scripts.

So it is most definitely the 'reader' button that is causing the delay - I was using article tags to display my content; switching to a standard div remedies the problem. FWIW, the delay goes from around 5 seconds with the reader button enabled, to under 1 second without it on iOS 6.

window.location.hash refresh in Chrome?

I was doing some snooping on the web and found window.location.hash = "etc" to be a widely adopted method to update the browser's location without reloading / refreshing the page. I've applied that to this example I've cooked up: http://dl.dropbox.com/u/1595444/locationExample/index.html
Works well in Safari, but...
What I've noticed is that in Chrome 10+ upon changing hash:
There is something similar to a reload.
The resulting symptom is a hiccup as the user scrolls down or up.
My console output is preserved (if you check your console the project string's are outputted).
The favicon seems to be reloading.
Has anyone run into this problem before? Know a fix?

There are most likely two things going on here:
The favicon and stop/refresh buttons flicker because of a Chrome bug (that mentions pushState, but hash changes are
on the same code path).
The slight hiccup when scrolling is because Chrome does a full page repaint and high-quality scale to update the page thumbnail, since it's considering hash changes as generating a new URL. That's also a bug. You can see this in the inspector timeline view, most scroll events result in a repaint of window width x some small height, but occasionally there will be a full-window repaint. This blog post has a few more details.
A workaround for both would be to defer the updating of the hash until the user is done scrolling (you can still update the white bar that appears under the current item immediately). You can do this by having something like:
var scrollTimeout;
window.onscroll = function() {
// update current item display here
if (scrollTimeout)
clearTimeout(scrollTimeout);
scrollTimeout = setTimeout(function() {
scrolTimeout = undefined;
// update hash here
}, 100);
};
Since it looks like you're using jQuery, there are debouncing plugins that may be helpful.

I don't have a definitive answer, but first I would try:
Prepending the hash mark (#) on to the value (i.e. use window.location.hash = "#etc").
Register a handler for the window.onhashchange handler.
Alternatively, you might consider using history.pushState if what you are trying to accomplish is make the back button return to the previous logical location (it's not clear to me what you are trying accomplish, whether you just want to jump to a section on the page, or something more complex).

var r='#hello';
if(navigator.userAgent.indexOf('Chrome/')!=-1){
top.history.pushState("", "", r);
return;
};
if(r.charAt(0)=='/'){
top.location.replace(r);
}else{
top.location.hash=r;
};
Worked for me. And it actually took me a long time to figure this out. Firefox also supports the history object now, so we may be able to get rid of the whole "hash" thing in a few years.
EDIT: Yes, the reloading thing is a Chrome bug.