I was testing a script which works fine on almost all desktop browsers and Android's chrome browser but when I tested it on Android version of Firefox Mobile browser I'm got wrong viewport dimensions.
So I decided to put together a small script to log the viewport dimensions at three stages [init (before load), after load and after a 1 second timeout]
http://kraftpixel.in/test/viewport.html
This is what I receive on my Moto-E android phone.
Also I noticed 'Dimensions after load' are random, On one occasion I noticed w=980 h=480 after load but presently I get the following result.
Initial dimensions : w=980 h=480
Dimensions after load : w=360 h=519
1 Sec after load via setTimeout() : w=360 h=519
Can someone please test this behavior on their android phone using the Firefox Mobile browser?
Suggestions are welcome but I need to execute the script before onLoad.
Its a script similar to those '(Pre)loading screens' on some websites.
I had the same problem that you and after some research I found that to have those properties correctly initialized you should wait until DOMContentLoaded is fired.
Try to modify your script using that event instead of onload and you will have the same result that when you fire the log function one second after load.
https://developer.mozilla.org/en-US/docs/Web/Events/DOMContentLoaded
Related
I am using a JavaScript library to arrange few images on the webpage. The following browsers:
Firefox
IE 11
Microsoft edge
render the page as it was planned, the problem occurs with Chrome browser. It messes up the complete layout.
The above browsers don't load any content unless all the images have been downloaded, until then it shows a blank white screen, and all of a sudden it will show all the content rendered perfectly. And in case of Chrome, the browser displays content on the go, as in you can see the images appearing in a scanline fashion.
I've tried calling the function that arranges these images inside:
$(window).load(function() {})
and it didn't fix the issue, I tried calling this in the <head></head> and also just before closing </body>, that didn't fix it either. Is this a Chrome related issue?
What should be the correct point in time where the function should be called?
There is a nice library on the web with a comprehensive name imagesLoaded designed to fix your issue! It is supposed to work cross-browser of course, so no differences in behaviour in Chrome or other browsers.
With its help, you can run your code at the moment when all images loaded in specific DOM element or elements controlled by jQuery selector. Like:
$('body').imagesLoaded( function() {
// images have loaded
});
There are also .done, .fail, .progress callbacks supported if you need, so check the docs.
In some cases you have to wait until the image loads to get a parameter not specified in the <img> tag, such as height for example. Then you may use $(window).load
In other cases, for example, adding some classes to the images, you can do it before the image load.
If you want to load the images after the page loads completely or when the user really scroll and see each image, Lazy Load is a good plugin and it support callbacks.
Images should load First as hidden, Then your script should run like
$(document).ready(function(){
// here do the scripting may be showing them one by one
});
I have a little problem. On my aspx page I have an iframe which contains grids, tables, etc and they always change their height obviously. The previous developer team solved the problem, that they set the height attribute of the iframe to constant 3500px. It's not so elegant way so I added a JS code, that automatically checks the content and adjust the iframe height.
I got the JS script from here:
iframe Auto Adjust Height as content changes
The issue is that, this js code works well in Chrome and Firefox and almost everytime in IE. Sometimes I got an error message in IE that says:
"unable to get property 'nodename' of undefined or null reference jquery" or "Invalid argument". From this time somehow the function inside the setInterval will never run again and that's why the iframe height will never be adjusted. I made some modification and this height checking function is called from body onload event. Theoretically this js script will run when the whole dom structure is loaded. Firefox and Chrome is Ok, and 8 times from 10 IE also works.
Can somebody help me? Is there any solution you can suggest me? Thanks a lot.
Execute your code within to ensure that it executes when the full page has been constructed:
$(document).ready(function(e) {
// .. iframe resize here
});
Sporadic failures like this on page load are almost always caused by executing JavaScript before the page is loaded and the DOM is ready.
I am developing a web-app utilizing Application Cache, and everything is working great on desktop browsers and on Android (even very old & slow android handsets). However downloading the appcache is taking much much much longer on iOS 6 in both Safari and Chrome.
My application cache total size is a mere 2.1Mb, and I have a pretty solid 70Mbps (download) internet connection. I would expect caching to be pretty rapid.
Here are my times so far:
Desktop Chrome: <1s (similar times for Safari & Firefox)
Android 2.3.3 Stock Browser: ~4s (similar times for Chrome & Dolphin)
Android 4.2.2 (Emulated): ~7s (running inside a PhoneGap app)
iPhone 4S 6.0 Safari: 8 minutes!!! (around the same in iOS Chrome too!!)
iPad 2 6.0 Safari: as above!!!
All of these devices are using the same wifi and internet connection, and my iPhone/iPad are otherwise functioning fine (no native apps exhibiting internet speed issues, and regular websites load just fine). There just seems to be something absolutely decimating AppCache download speed under iOS.
The window.applicationCache.status throughout this time is appCache.DOWNLOADING, and I have a progress event running counting the files as they are downloaded, so I'm certain that it is not stuck elsewhere. This just appears to be the time it takes to download. What gives?
Addendum : The iPhone also runs ridiculously hot, and the battery ticks down very quickly during this operation. It seems that something is causing the CPU to run flat-out during this download.
(Note: I can't publish a link to the web-app here as we're still in private beta, but if you would need to see it before you think you'd be able to help diagnose it, email me at the address in my profile and I'll send a link to the app).
Okay, I figured it out with the help of the iOS Emulator, and Xcode Instruments to profile it. (I'm not sure if I should add my solution into the main question, or as an answer, but I thought I'd do it this way as my question is already a little cluttered).
As it turns out, it was actually some erroneous javascript causing the issue, but apparently only on iOS.
The web-app is intended to only be a single page high (no vertical scrolling, except within specific DIVs), so in addition to the usual standard JS code for hiding the address bar...
window.addEventListener("load",function() {
// Set a timeout...
setTimeout(function(){
// Hide the address bar!
window.scrollTo(0, 1);
}, 0);
});
...I had also added in the following:
$(document).scroll(
function(e){
window.scrollTo(0, 1);
});
From looking at the profile results, I was able to see that a lot of time was being spent in scrollTo, so it immediately pointed to this as the cause. Why the scroll event was being triggered so much, I have no idea (this was occurring with no touching of the screen whatsoever).
My initial fix is to throttle that code, but I am now evaluating whether or not I even need it at all. Here is the code I have that fixes it for now (using jquery-debounce, which I was already using for something else):
$(document).scroll(
$.throttle(function(e){
window.scrollTo(0, 1);
})
, 10);
The download time of the application cache is now in line with the Android times. Phew!
The code is getting itself into an infinite loop, as the initial scrollTo function call triggers the scroll event handler, which then repeatedly re-triggers itself! My best guess is that the iOS JavaScript engine handles this infinite loop differently to the other browsers' JavaScript engines.
i have a problem in iPad Safari. when i use Javascript to append image to div using elm.appendChild(img) the images don't appear until the screen is touched. the same code works perfect on IE,Firefox,Chrome,and android browsers.
i have uploaded video that shows the problem. http://www.youtube.com/watch?v=nBN9fThDik8
is it related to the device ? or there some special code for loading images in iPad safari?
or any solution ?
iPad (more so than iPhone as far as I've experienced, although that's just a gut feeling) is notorious for avoiding loading and rendering large resources unless it decides the user is going to see them.
How about faking the user input required to trigger the render, ie the scroll, after appending the image? Sample code here, may work:
function scroll(){
var body = document.body;
var xy = [body.scrollLeft, body.scrollTop];
window.scrollTo(xy[0],xy[1]+1);
window.scrollTo(xy[0],xy[1]);
};
To be called immediately afterwards, eg:
appendImg();
scroll();
I have an iframe on my index.html and this iframe is dynamic.
on my index.html I have a form, which when submitted, shows the results inside the iframe.
The problem is the Iframes height also has to be dynamic for the website to look "clean".
So in the Iframes php page, I have this code:
<body onload="parent.resize_iframe(document.body.scrollHeight)">
And in the index.html (which is the parent in this case) I have this function:
function resize_iframe(new_height){
byId('iframe001').style.height=parseInt(new_height) + 20 + 'px';
}
The problem here is not the function, but that Safari and Chrome thinks the scrollHeight is something alot bigger than it is.
I have tried alerting the scrollHeight, and the nr is always around 2000px in Chrome and Safari, but in other browsers it is dynamic as it should be (500, 300, 800 etc)...
Any ideas?
UPDATE:
I noticed when I click a link on the index, and then click the browser back button, the iframe DOES resize correctly in SAFARI and CHROME.
But I must click back in the browser for it to work...
SEE THIS QUESTION FOR FURTHER INFORMATION: Can't figure out why Chrome/Safari can't get the ScrollHeight right here
I am not sure but however I want to say what I want say. Safari and Chrome both webkit based browsers so its normal to behaviour like that. So I guess that they calculating the height adding padding and margin to normal height. please google it "webkit calculated style"
Sometimes javascript does not work as expected when the page has validation errors.
First try validating your markup (HTML).
If validating does not work, try using jQuery.
jQuery is cross-browser compatible; you should get the exact same result on every browser.