We Keep Coding

Best method of displaying an alternative on javascript crash

Im looking for a very general method of providing an alternative site to a Javascript heavy site (a link going to the old static site).
My current implementation is:
//<Some JS/HTML>
$(document).ready(function() {
//<Some JS Code>
$('#error').attr('style','display: none;');
});
//<Some html>
<div id="error">
<span>If you can see this, that means something went very very wrong. Click Here to use the old portal. Please contact some#email.com with this error and provide as much information as possible, thank you :) </span>
</div>
My current problem is that this is visible while the site is loading :(. Is there a better method?
I know i can try and add lots of trys and catchs (theres already several), but the problem is the primary clients are going to be using a mixture of clients between. FF2-FF3, all version in between, and IE5-IE6. The IE5 im just placing a messagebox and redirection if they try to load the site, im not even going to try and make that compatible.
And these old browsers just are not compatible with certain things.... I know i could add in an .onerror, but FF didn't add compatibility until FF6 which is to new for most of the clients. (although strangely, IE5.5 has it)
NOTE: Im just jQuery 1.7.1
The basic flow of the current operation is just when it finishes loading the initial javascript it hides the div.

You can use mainly CSS with a JS helper for this.
Put this JS code as close to the top of the document as you dare, preferibly after the charset declaration. You will need to include jQuery before this line or you can use standard JS (document.getElementByID('html-tag').className='js';, this assumes you've given the html tag an id of html-tag):
$('html').addClass('js');
Then you can write your CSS to take into account the fact that JS may or may not be available:
#error {
display : block;/*if no JavaScript is available then show this element*/
}
.js #error {
display : none;/*if JavaScript is available then hide this element*/
}
Here is a demo: http://jsfiddle.net/x4tjL/ (JSFiddle seems to be having problems right now, here is a JSBin: http://jsbin.com/ahezuc/edit#preview)
Update
Putting the JavaScript code as near the top of the document and not wrapping the code in a document.ready event handler allows you to minimize the "flash" of content that is common when trying to hide/show content based on JS.

A simple solution would be to detect all incompatible browsers and show the message to upgrade their browser or to redirect to non js site, something like:
for IE5 and 6
if ($.browser.msie && $.browser.version <= 6){
//show my message here
}

Has Chrome browser broken dynamic script loading?

This isn't my code, I'm just troubleshooting it. Some code that has been working for over a year has now stopped working in Chrome (12.0.742.122), but works in the other "big" browsers (including fellow WebKit stablemate Safari (5.0.5)). By "not working anymore" I mean that although the script file does load, it doesn't execute. The kind of behaviour you'd expect if loading a script into innerHTML or writing it into a div, but neither of which things are being done. The commented-out lines below were all failed attempts at getting it working, the first of those being the original code that had worked up until recently.
<div id="abc"></div>
<script type="text/javascript">
var d=document.getElementById("abc");
var s=document.createElement('SCRIPT');
if(s){s.src=script_path;}
//if(d)d.appendChild(s); //original line that still works in all other browsers
//if(d)d.parentNode.appendChild(s);
//if(d)d.parentNode.insertBefore(s,d);
//if(d)d.parentNode.insertBefore(s,d.nextSibling);
document.body.appendChild(s); //this works, script executes
</script>
What is wanted from this code above, is that the script is a child of the div. Presumably they want to be able to remove that child and have all script be removed at the same time (I'm not sure of their motivation).

I've discovered what the problem was, largely thanks to Martin Bieder's back and forth and introducing me to jsfiddle.net with his working example.
The issue was actually the test page and what you'd think would be a fairly harmless error they made in creating it. The div and all of the code will be represented below simply as ######, as it's not even relevant to the problem. It's actually a HTML problem. Chrome 12 isn't happy if you don't match up your closing tags properly. I really can't believe that it has an effect on the execution on script files, but it does. I've tried many many times in the last 10 minutes with the HTML tags right and wrong and unbelievably this really is the problem.
<font><center><b>
##########
</b></font></center>
You see how the font and center closing tags are the wrong way around, and that's enough to confuse Chrome sufficiently that it won't execute any dynamic script being added within those tags. Bizarre. I can't recreate this on jsfiddle, probably due to the nature of the site runs the html/js that you put onto it (using onload for example).

No it works. Google Analytics uses is, too.
var ga=document.createElement('script');
ga.type='text/javascript';
ga.async=true;
ga.src='http://www.google-analytics.com/ga.js';
var s=document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(ga,s);

Have you tried to set to async the script element?
var script = document.createElement('script');
script.async = 'async';

It is all about 3 things.. Organization, Optimization, and debugging.
1)properly scoping your tags makes things easier to read.
2)properly organizing your code makes it easier to parse which means parsers can be faster and more efficient.
3)alot of the debug tools we use rely on this organization in order to display things like collapsible tags and present a more visual scoping

Javascript debugging issue with colorbox

Ive recently been making structure and style edits to http://washingtongraphic.com/logo-design.html and found that the colorbox plugin no longer works. When you roll over each logo, it should pop-up to a larger size and go back to its normal state when you roll out. In addition, when clicked, it should appear in the colorbox window… this also does not work. All of the links to the scripts and other resources appear to be correct, but for some reason, the script is not triggered on roll-over and the colorbox window also does not appear when clicked. A functional example (of how it should be working) can be found here: http://washingtongraphic.com/annual-reports.html. Im not very good at debugging javascript yet and can really use all of the help I can get. I have been using firebug but am not sure how to tell where the script is failing. Thank you all in advance.
Also, I did not create this site but am merely editing it… its not how I would have built it (I know there are some other structure issues here!)

The issue is the load order of trialbyfire.js and trialbygallery.js.
Make sure they're loaded in this order (you have them reversed on the logo-design page):
<script src="js/trialbygallery.js" type="text/javascript"></script>
<script src="js/trialbyfire.js" type="text/javascript"></script>
Additionally, to fix this error, you have two choices:
Uncaught TypeError: Object #<Object> has no method 'scrollable' on trialbyfire.js:89
Remove:
// Mousewheel
// execute your scripts when DOM is ready. this is a good habit
$(function() {
// initialize scrollable with mousewheel support
$(".scrollable").scrollable({ vertical: true, mousewheel: true });
});
Fix the 'scrollable' dependency. Likely a plugin that should be loaded, but isn't.

IE: why isn't AJAX resulting HTML updated in DOM?

I'm loading html content via ajax onto a div (using mootools 1.11 and squeezebox, if it matters).
In the content that I load I have some JS that manipulates some of the loaded HTML objects.
Everything works fine in FF, but when I load it in IE (tested on IE7 for now) the code fails with "'null' is null or not an object.
A quick test shows that the new elements loaded by AJAX are not in the IE DOM. Loaded a div with id 'test' and when I ran document.getElementById('test') I got null. Needless to say running getElementById on original elements works fine.
Does anyone know how to solve / work around this problem?
Some more information:
I put my code inside the window 'domready'. Tried using 'load' event, but then IE never called it.
UPDATE
as advised, I checked the same script on IE8 with it's better debugging abilities.
It seems that the problem is indeed in the timing. I run my code at the windows's domReady, and it seems to run instantly, without really waiting for the DOM to be ready (in the popup window). Running the same script using the debugger, once the whole page has loaded, locates the elements with no problem.
So I guess the question now is how to make the script run at the proper time.
domready event seems to fire well before the dom is ready
load event seems not to fire at all
putting the script at the end of the file, after the HTML objects, doesn't help as well
In the Mootools AJAX options, I indicate 'evalScripts' as true, otherwise the script doesn't run at all
any ideas?

there is nothing that prevents IE from loading elements into the dom. there is also no such thing as 'domready' after updating an innerHTML property. consider this:
new Ajax("someurl", {
method: "get",
evalScripts: true,
onComplete: function() {
$("someid").setHTML(this.response.text); // load content.
}
}).request();
now, the question here is, does evalScripts run BEFORE the onComplete or after. i take it the script that you send back is relevant to the markup that you use to update?
the source code for 1.11 goes:
onComplete: function(){
if (this.options.update) $(this.options.update).empty().setHTML(this.response.text);
if (this.options.evalScripts || this.options.evalResponse) this.evalScripts();
this.fireEvent('onComplete', [this.response.text, this.response.xml], 20);
},
which indicates that scripts are evaluated after the update: and before the onComplete, so using:
update: $('somediv'),
evalScripts: true
ought to work. if it does not, then i would suggest trying:
new Ajax("someurl", {
method: "get",
onComplete: function() {
$("someid").setHTML(this.response.text); // load content.
this.evalScripts();
// or if it fails still, delay it:
/*
if (window.ie)
(function() {
this.evalScripts();
}).delay(100, this);
*/
}
}).request();

You may want to test on IE8 and use the IE Web developer tools to see what is really happening, to see if there was an error somewhere.
You can also get this plugin for IE7, though I remember it being improved for IE8.
This way you can get a better idea what is going wrong, and then update your question and we can help with less guessing.

Some test ideas:
- Did you try to use old fassion xmlHttpRequest methods to see if it works without frameworks?
- Check your document DOCTYPE, maybe you have an html/xml content type issues that affect only IE
- Are you sure the object you are trying manipulate already exist when you access it? IE is way slower than FF.
- Did you try to use some other AJAX methods or DOM manipulations to see maybe the problem is less specific?
- Did you check your HTML validity? maybe you have some malformed HTML that FF is able to parse but IE doesn't.

For what it's worth, here's a Prototype version of Dimitar Christoffs answer:
new Ajax.Request('someurl', {
parameters: param,
onComplete: function(transport) {
/* eval scripts first */
transport.responseText.evalScripts();
/* rest of onComplete code */
/* ... */
}
});
This ensures that the embedded scripts are evaluated before executing the rest of the onComplete callback (which is, as of Prototype 1.7.1, NOT the default behaviour).

There may be some version skew issues -- current squeezebox requires mootools 1.2 (and doesn't use setHTML any more, cfr here for issues another tool had with it); you sure your squeezebox and mootools are in compatible releases (and fully support IE)? Maybe just upgrading both to the latest release would fix your problem (worth trying!).

Making Firebug break inside dynamically loaded javascript

I'm looking for a way to debug a dynamically loaded jQuery document.ready function.
Obviously I can't just bring up the script panel and add a breakpoint with the mouse since the function does not exist there.
I've also tried adding "debugger;" to the function (without the quotes), but that did not do anything. I have ensured that the function is actually executed while I tried this.
Thanks for your help,
Adrian
Edit: I just noticed that Firebug actually breaks on debug. However, when it does so on a dynamically loaded script, it does not bring up the source code of that script as usual. Plus, the call stack ends right below my own code. I can bring up the implementation for document.ready via the call stack, but that does not really help. Is this a Firebug bug or have I missed something?

I just worked on this similar question. The solution involves adding the word debugger twice; once at the top of the external file and one more time at the top of the function that needs to be debugged.
I noticed that if the debugger word was used only once, it did not work. Example:
//myExternal.js
debugger;
function myExternalFunction(){
debugger;
/* do something here */
}

You might try placing a break point where the event is called, and then instead of click "Play", choose "Step Into" (F11). I don't have a test case in front of me, but I think this may work.

I don't know if you ever got this figured out, but in case someone else needs it...
I got around this by moving the code I wanted to debug to an external file that was linked from the main page.
In my case, I had default.aspx loading services.aspx into a content div using jQuery AJAX. Services.aspx in turn, was loading jQuery UI tab elements using AJAX from a webservice that was providing it data. The webservice code was in a file called data.js which was linked from default.aspx. I needed to debug the code that was in the header of services.aspx (that loaded the tabs with data), but couldn't ever see it in any of the available inspectors. I just moved the code I needed to a new function in data.js and called it from the header in services.aspx.
I hope that makes sense to someone who needs it!

Just encountered same behavior (Firebug ignoring debugger; statement in dynamically loaded code) in Firefox 5.0/Firebug 1.7.3.
Worked around by detaching Firebug window ("Open Firebug in New Window").

There's also a 'debugger' keyword that's supported by the IE JScript debugger, and Safari's Web Inspector, so i would be surprised ifit wasn't supported in firebug.
Basically:
// mydynamicallyloadedfile.js
... // do stuff
debugger; // triggers debugger
... // more stuff
And i would expect firebug to break at the debugger keyword