I'm trying to lazy load javascripts, but I can't get it to work reliably. My pages load quite quickly and I want to keep it that way, so I'm not about to use a timeout to delay the loading. Besides document.readyState, how do I ensure the DOM is genuinely ready for modification?
Method I:
poll readyState
createElement script
src = url
appendElement to head
Results:
IE8: always aborts
FF3: loads first time, aborts every
other
Chrome: loads first time, aborts every
other
Method II: (lazyload included in head tag)
load with lazyload
Results:
IE8: always aborts
FF3: works
Chrome: loads first time, aborts every
other
If you put your <script> tag just above the </body> tag, you could do most things with DOM without it raising any errors, i.e. anything that is above the <script> tag is usually up for modification.
However, if you are looking for a more robust solution, you might have some progress by checking out how the major libraries are detecting if the DOM is ready, here's one for starters (jQuery): http://github.com/jquery/jquery/blob/master/src/core.js#L393
Javascript is hardly usable cross-browsers without a decent framework to help you span the differences. Probably most popular today is jquery, where, per this tutorial, you could use $(document).ready(). In dojo, also quite popular, you could use addOnLoad. And so on... and if you aren't using any framework, you're making life too hard for yourself: do yourself a favor and pick a JS framework you like!-)
Related
This is not a real coding question, more of a real-world statement.
I have previously noted that DOMReady events are slow, very slow. So, I noticed while browsing the jQuery source that the jQuery domeready event can be trigger using $.ready(). Then I thought, placing this simple execution script just before closing the body should trigger all the "onDomReady" listeners that where previoulsy attached. And yes, it works as expected:
<script>$.ready()</script>
</body>
Here are two examples, this one measures the ms spent while waiting for DOMReady:
http://jsbin.com/aqifon/10
As you can see, the DOMReady trigger is very natively slow, the user has to wait for a whole 200-300 milliseconds before the domready script kick in.
Anyway, if we place $.ready() just before closing the BODY tag we get this:
http://jsbin.com/aqifon/16
See the difference? By triggering domready manually, we can cut off 100-300 ms of execution delay. This is a major deal, because we can rely on jQuery to take care of DOM manipulations before we see them.
Now, to a question, I have never seen this being recommended or discussed before, but still it seems like a major performance issue. Everything is about optimizing the code itself, which is good of course, but it is in vain if the execution is delayed for such a long time that the user sees a "flash of "unjQueryedContent".
Any ideas why this is not discussed/recommended more frequently?
By triggering the event yourself, you are stating to your ready() handlers that your dom has been loaded BUT it may not have been! There is no short cutting the DOM ready event. If there is indeed a long wait time, then employ the amazing debugging tools of firebug, chrome, etc.... check your resources and their timing ques. It's all there in black and white and will indicate what is taking so long (the requests, the rendering, how many resources, etc.. )
Any ideas why this is not discussed/recommended more frequently?
Placing JavaScript just before </body> has been discussed a lot, and as you know it's recommended if you're looking for faster page loads. Manually triggering the jQuery ready handlers is in fact poorly discussed. Why? Well, I don't think there is one single objective answer to that, but I'll try to outline some possibilities here:
Performance is not the main goal of jQuery (anthough it's definitely a concern), and performance freaks will usually look for lighter libraries for cross-browser DOM manipulation and event handling, or roll their own.
It's an extra step, and it doesn't look clean. jQuery tries to be clean and elegant, and recommending an extra step to initialize scripts doesn't sound like something that's gonna happen. They recommend binding to ready, so recommending to force .ready() and ignoring the actual browser event looks "wrong". Whoever is concerned about that probably knows that initializing scripts right before </body> is faster.
Optimizing DOMContentLoaded sounds like a task for browser vendors. I'm not sure why it's slower, though, and maybe there's not much room for optimization – in my understanding, calling init scripts before </body> should always be the fastest way to initialize stuff (as it's executed immediately when parsing the container <script> tag, while browsers must finish parsing the whole file before triggering DOMContentLoaded).
You probably remember that not so long ago it was common practice to have <script> blocks scattered everywhere on the HTML. Then the Web Standards movement came, and recommended more sane and maintanable ways to do things. That included bootstraping scripts from a single place – initially, window.onload, which was then considered problematic for being slow, then DOMContentLoaded and its emulations for IE8 and below. However, we still see spaghetti-HTML with scripts everywhere on a daily basis here on StackOverflow. So I'm not sure if recommending placing scripts before the end of the body is a good call today, because it may be interpreted as a license to add scripts anywhere within the body.
Finally, if you're really concerned about loading your script fast, and your code does not manipulate the DOM, the fastest way to load it is to put it in the <head> before any stylesheets. And I'm stating that just to say that there's no silver bullet, no optimal way to init scripts that is the fastest and most elegant in every scenario. I think that's why the community sticks with recommending something that looks sane and tends to create more maintainable code, instead of other better performing alternatives.
Actually, placing a function call before </body> tag makes it pointless to use jQuery's ready(). Just put native JS-wrapper function call that contains calls of all other functions that should be called on document ready.
In general, it's a working (though somewhat littering HTML code and therefore unacceptable for perfectionists) alternative for situations when author does not need/want to use jQuery at all. In such situations though, I would prefer to use native DOMContentLoaded event handler that is supported by most of browsers including IE9+ (for IE8- we can use window.load() as an acceptable fallback).
Using IE8 and headjs
I have a template header template file that has a head.ready(function(){}) in it. This page is loaded my all my pages.
On some page, I have scripts in the code that call the head.ready (which means it would be on the page twice because of the above header template). I noticed that putting an additional head.ready(function(){}) works in Chrome/FF, however it appears not to work in IE8. Only the first ready call seems to work. The second one does not fire.
Does anyone know if this is an issue in IE8 and if there is a simple workaround?
It might be an untested bug with IE8.
You'll probably have to poke at the source code which is never fun or try reporting it to the author.
Did you try any alternatives? YepNope? RequireJS? LabJS?
I wrote my own to be as small and simple as possible:
https://github.com/sgarbesi/fallback.js
So, I'm trying to find an answer to why this problem is happening; I've fixed the problem, but I want to know why it happened.
TL;DR
Google-provided conversion tracking code that injected an iframe using document.write suddenly caused the page to cease to execute in all versions of Internet Explorer, but was remedied by injecting the same iframe using a non-document.write method.
The Story:
Doubleclick is an advertising network that provides a JavaScript snippet to track conversions from ads.
The snippet they give looks like this:
<SCRIPT language="JavaScript">
var axel = Math.random()+"";
var a = axel * 10000000000000;
document.write('<IFRAME SRC="https://fls.doubleclick.net/activityi;src=143;type=donat01;cat=indir4;ord=1;num='+ a + '?" WIDTH=10 HEIGHT=10 FRAMEBORDER=0></IFRAME>');
</SCRIPT>
<NOSCRIPT>
<IFRAME SRC="https://fls.doubleclick.net/activityi;src=143;type=donat01;cat=indir4;ord=1;num=1?"
WIDTH=1 HEIGHT=1 FRAMEBORDER=0></IFRAME>
</NOSCRIPT>
Now, I know that, for all sorts of reasons, document.write is hazardous and should be avoided. But, Google is giving me this code, so, I figured I could trust it.
It suddenly started breaking all of our pages for all users using Internet Explorer. As in, the page would stop rendering entirely once it hit the document.write. This was crazy: One of the largest third party advertisers on the internet had given me JavaScript that had LITERALLY broken my purchase pages for 25% of my traffic!
As triage, I quickly substituted in the same code using the injection technique found in Google Analytics:
var iframe = document.createElement('iframe');
iframe.src = //the URL;
iframe.width = 0;
iframe.height = 0;
iframe.frameborder = 0;
var ref = document.getElementsByTagName('script')[0];
ref.parentNode.insertBefore(iframe, ref);
This resolved the problem, without actually explaining:
Why does a nearly empty iframe, injected using document.write, break Internet Explorer, but this method above doesn't?
I've solved the problem; it turns out that it had nothing to do with the contents of the <iframe>.
It turns out the page is served by a framework that began using a backend DOM parser that, for reasons likely related to the presence of </ within a <script> tag within the document.write, completely removes the </iframe> closing tag from the generated page, even though it preserves it in the backend. (It's probably trying to enforce ETAGO rules).
The reason I was able to reproduce it was because I was copying the generated document.write code, not the original code, and never noticed the missing </iframe>. (And my "functioning" document.write code didn't have the stripped out </iframe> tag, leading me to believe that the problem was the contents of the iframe.)
As a result, browsers parsed an unclosed <iframe> tag on the page, which Internet Explorer didn't know how to handle, and died part way through the parsing of the iframe (I'm still not totally sure why).
document.write() blocks further page rendering until it finishes. I assume that the remote script was taking a while to load, and thus blocking the rest of the page from loading.
I also assume that Math.Random() function doesn't help matters.
Also...Google's tracking codes scare me...they tend to be ugly hacks of javascript.
There is 2 reasons why the first method should be slow.
document.write() blocks until it is actually performed
the window’s onload event doesn’t fire until all its iframes, and all the resources in these iframes, have fully loaded
Your solution works because the iframe it creates does not request the remote url until after the onload event. Having a set timeout on the first code, you would also get the page to load, then the request to the remote url to fire.
As to why the change of code broke the site, I can not seem to find any speed differences transferring between the two. Maybe it seemed faster because it was cached.
I don't know about the structure of your site, but normally the first script tag is in the <head>. An iframe in the <head> wouldn't be rendered. I'll wager if you did document.body.getElementsByTagName('script')[0] you would probably have similar issues to the one you described above.
Seems you're having a similar problem that I had several months back. The document.write triggers, and overwrites the page. Just use the iframe directly, and everything should be kosher.
I tried replicating your issue but couldn't on IE9.
Either I don't have the right test setup or it seems IE prior to IE 9 had some bug. Firefox had a simialr bug: https://bugzilla.mozilla.org/show_bug.cgi?id=293633
Maybe its a combination of unclosed iframe and something inside the page that's being rendered.
I have a site that I put:
<body onload="ajaxLoad()" >
I have a Javascript function that then inserts data from my database into the text editor by using the setContent Javascript method of the textarea. It seems fine in Firefox and IE but in Chrome sometimes nothing shows up. There is no error, just a blank editor.
In the body section I have:
<textarea id="elm1" name="elm1" rows="40" cols="60" style="width: 100%">
</textarea>
In the head section I have:
function ajaxLoad() {
var ed = tinyMCE.get('elm1');
ed.setProgressState(1); // Show progress
window.setTimeout(function() {
ed.setProgressState(0); // Hide progress
ed.setContent('<p style="text-align: center;"><strong><br /><span style="font-size: small;">General Manager's Corner</span></strong></p><p style="text-align: center;">August 2009</p><p>It’s been 15<sup>th</sup> and so have a Steak Night (Saturday, 15<sup>th</sup>) and a shore Dinner planned (Saturday, 22<sup>nd</sup>) this month. urday, September 5<sup>th</sup>. e a can’t missed evening, shas extended it one additional week. The last clinic will be the week of August 11<sup>th</sup>. </p><p> Alt (Tuesday through Thursday) </p><p> I wouClub.</p><p> </p><p> </p><p> </p><p> <strong></strong></p>');
}, 1);
}
I am not sure if its some of the formatting that Chrome is rejecting but it seems like if TinyMCE can parse it in one browser, it should be able to do it in any browser, so I am confused.
Any suggestions?
Background:
For various reasons onload() is not considered the proper approach for loading Javascript, see for example Launching Code on Document Ready, with the most important/noticeable one being that Javascript code isn't run until the page has finished downloading entirely, including images and the like, which might take an eternity therefore (e.g. if an external banner ad server is down etc.).
Instead it is recommended to load Javascript as soon as the DOM is ready, but unfortunately there is no cross browser compatible native solution for this, see Getting notified when the page DOM has loaded (but before window.onload); please note that my entire answer is based upon the most excellent Javascript library jQuery, which offers a cross browser solution for this problem, consequently I'd definitely favor the two higher voted answers over the accepted solution myself.
Likely cause:
Your issue seems to be caused by the opposite behavior though: Chrome facilitates the WebKit rendering engine, just like Safari, and for the latter onload() is discussed to behave differently, see section When does onload fire? in Is Safari faster?. Another description of this problem specific to Chrome can be found in window.onload not working correctly in Chrome, without an explanation though.
In conclusion I suspect onload() to fire before the DOM is actually loaded completely, at least concerning the requirements of TinyMCE, which is notoriously fragile regarding issues like this and simply ceases to load.
Possible solution:
Just facilitating attribute defer on the script tag as outlined in window.onload not working correctly in Chrome is again not cross browser compatible, hence I'd simply go with the widely deployed and proven approach of using the already mentioned jQuery cross browser solution for the onload() problem, which is good practice anyway and should in principle take care of your inverse issue as well.
Update:
There are indeed some bugs filed against WebKit which could back my conclusion (no matter whether this behavior actually constitutes a bug or is intentional), see:
onload sometimes fired before all resources are loaded
window.onload fires before all subresources loaded
Window.onload is firing before image resources are loaded
I had a similar problem (editor not showing in chrome) and read in some forum, that if tinyMCE is unable to locate some files, it just stops loading. Try tracking down if everything is found using firebug's net tab (clear your cache first).
First of all; see to it that you have the latest version of TinyMCE.
I could not reproduce your problem given the information you provides. It seems just fine ( with the faked ajaxload ).
You could always try to go the "back entrance" in;
var myed = document.getElementById('elm1_ifr');
myed.contentDocument.getElementById('tinymce').innerHTML="<p style=\"text-align: center;\"><strong>hacking <span style=\"font-size: small;\">my</span> way in.</strong></p>";
Hope you good luck!
SOLUTION:
Ive been struggling with the TinyMCE toolbar not appearing in all kinds of secnarios....it would work in one user's IE browser, but not another. It would not work in Firefox or Chrome, etc.
Turns out if in the newest 3.3 version there are STILL bugs they have not fixed. This one occurs when in your webpage JavaScript code, where you instantiate the TinyMCE, if you added code for the plugin part where you load up two specific plugins, the toolbar fails to appear and you see HTML:
plugins:
"safari,spellchecker,pagebreak,style,layer,table,save,advhr,advimage,advlink,emotions,iespell,
inlinepopups,insertdatetime,preview,media,searchreplace,print,contextmenu,paste,directionality,
fullscreen,noneditable,visualchars,nonbreaking,xhtmlxtras,template,**imagemanager,filemanager**",
Remove all references to imagemanager and filemanager in your web page, then refresh your browser...
When you do, retest in Chrome and Firefox and IE and the TinyMCE suddenly appears! Wow....a miracle, huh?
Turns out their "main developer" hasn't fixed the issue but does explain it as such, if you want to try and still use those plugins and yet fix the problem. His quote is as follows:
"If the ImageManager/FileManager are old they might not use the new
scriptloader api. And the new 3.3 version will load all dependent
scripts async instead of sync. - Spocke - Main developer of TinyMCE"
There are a few ways to set content in a TinyMCE editor. If you want the content to be there when the page first loads, you can just put it between the tags.
Otherwise, you can do this through script in the following way:
window.onload = function() {
tinyMCE.getInstanceById("ProfileText").setContent('test');
};
I have wrapped the code in a window.onload block. If you have other functions that set content dynamically through this way after the TinyMCE editor has already loaded, then you do not need that.
There is an option oninit for the function tinyMCE.init(), put your method there:
tinyMCE.init({
oninit: function(){
tinyMCE.activeEditor.setContent('blah');
}
});
It works this way.
The editor is not fully loaded on document load event, as it the editor loader will post-load a bunch of files.
same problem here, ie needs
var ed = tinyMCE.get('content');
ed.setContent('zzz');
other browsers
document.getElementById("content").innerHTML="zzz";
i am quite disapointed
will need to check browser in javascript to get it working properly, thats suxx
I'm new to Firebug and having a lot of trouble.
JavaScript files usually show up empty, or load partially (some of the time)
Lines are not available to set breakpoints on frequently (line numbers are greyed out)
When I do set breakpoints, script execution often does not stop on them
I'm using Firebug 1.3.3 and Firefox 3.0.11. I have disabled all other Add-ons. I'm loading Javascript from localhost. Sometimes closing the window and re-opening the page I was on clears things up, but that never lasts for more than a couple page loads.
I'm working on learning jQuery, which obviously has a huge library, but I imagine many other people use Firebug for the same, so that shouldn't be a problem. Also, most of the time (but not always), Firefox loads and executes the JavaScript no problem; just Firebug can't see it.
Due diligence:
These discussions seem to cover the same problem, but have no answers:
"Firebug not showing Javscript errors" - http ://groups.google.com/group/firebug/browse_thread/thread/443848cd11be48e1?pli=1
"firebug does not always load javascript" - http ://code.google.com/p/fbug/issues/detail?id=1644&q=empty%20javascript&colspec=ID%20Type%20Status%20Owner%20Test%20Summary
(Sorry I'm new, and not allowed to hyperlink those)
A couple suggestions. Make sure that you have the console, net, and script panels of Firebug all turned on.
You should see in the net panel what js files have downloaded. In the console panel, you should be able to type console.log(jQuery) and get back function().
This should confirm that jQuery is actually loaded and running.
Then go to your script panel, and you should see four options across the top. Inspect, Edit, Static, and then a drop down list of your scripts. That's the one you want. Select the script that you want to debug.
Based on your question, you probably know some of this already, but confirm that all of that is working first.
When you don't see jQuery in the scripts list, can you do console.log(jQuery)?
PS. It's not a matter of size. I routinely load js files that are 10x the size of jQuery.
Edit: A few more suggestions:
1) Reduce to simplest case and add back. Remove all your scripts other than jQuery and then add your other scripts incrementally. Is there one that consistently breaks it.
2) Put try / catch statements around suspicious code blocks. I've often found that FB stops reporting errors after an uncaught exception has been thrown.
try {
// your code here
} catch (e) {
console.log(e)
}
3) Setup another FF profile to test if you get the same problem.