Before I forget I thought I'd write down the fun I had implementing the gadgets feature. The idea was pretty simple, adding a little bit of HTML into your web page would show your latest tagged items; there would be a customization page allowing the user to pick different themes and the number of items to show etc... If you change any of the customization options the preview to the right of the options changes accordingly; the page can be seen below:

So how does it work? When the user changes an option a function gets called that adds a script element in the preview area; if a script element is already there its URI is changed with new parameters. The preview gadget is effectively the same script that you see in the edit box, all pretty simple; however things didn't work quite as I expected.  Under IE when changing options it would literally crash (not a good start) and under Firefox, well, nothing happened.

Tools of the Trade

I needed to see what was going on under the hoods of both web browsers, I wanted to look at the underlying elements that were changing dynamically; so I downloaded Developer Toolbar for IE and Firebug  Firefox.  I also used Visual Studio to debug the JavaScript for IE and FireBug for Firefox.

Debugger woes

 To debug JavaScript running in IE you need to enable debugging in its options dialog:

So that's what I did, I unchecked the relevant boxes and sat in Visual Studio waiting to put a breakpoint on my code.....Nothing happened, I had another look in the IE options dialog, looking for a setting I might of missed and found to my surprise, that the boxes I'd previously unchecked had magically checked themselves again. I noticed that if I set the Internet options via Control Panel the check boxes stayed unchecked, but as soon as I fired up IE they were set again. Using the registry monitor RegMon I could see that the registry entries for the check boxes were being continually set whilst IE was open. I had a hunch that a piece of software I had installed called Spyware Doctor was causing the problem, so I uninstalled it and the problem went away. I'd spent the best part of two hours on this waste of time; I sent Spyware Doctor support a email telling them the problem; I got a reply saying I should disable it whilst doing debugging, needless to say I uninstalled it. Its a shame I paid good money on it :-(

To crash or not to crash? That's the question

Internet Explorers answer was "I'm going to crash", I debugged into IE using Visual Studio and there wasn't much info I could get out of just the hex information via the stack so I setup Symbol Server (Instructions here on how to install): Now the call stack looked much better:

This gave me a clue what I was doing wrong; of course IE shouldn't crash so I'll be raising a bug with MS about this. What I was doing wrong was inserting a script element as a child of a div and then replacing all the contents when the script ran with the widget HTML...I got around this by creating another div and inserting the dynamic HTML into that instead, keeping the script element separate. If your interested you can see a small example I knocked up reproducing the crash here, once downloaded you need to unzip the contents in c:\CrashIE and then run the test page (I couldn't find out how to do relative file based paths).

Don't forget to split your script element

I had a weird error that made me scratch my head for a few moments; I had the following bit of script (in italics):

element = "<script type=\"text/javascript\" src=\"" + uri +"\"></script>". 

This code snippet was used to insert a script element into the document; what I found happening when running the associated web page was that some of my script was actually appearing as text in the page; basically if you have </script> even in a text literal then the HTML processor treats it as the end of the script block. The solution was to split the text up like "</" + "script". You may also notice that I explicitly close the script element with a closing </script> element rather than <script type=\"text/javascript\" src="..." />; the answer is the the latter doesn't work, for a better explanaition than I could give go here.

Whatever happened to Document.write

In the very distant past when I wrote a similar gadget for MyDigiGuide I used document.write to insert dynamic HTML, but it doesn't work when the document is XHTML.  The alternative I use is to find the element I want to insert the HTML into, and then set the innerHTML attribute with my gadget HTML. This is the reason that the snippet the user gets to put into their website has a div with a unique identifier; Document.Write had the nice feature of placing the output where the script was, which we don't get when using InnerHTML, so I use the div identifier as the insertion point.

Two bugs with the same symptoms working in unison against me 

When I initially wrote the customization page for the gadgets I noticed that whenever I changed an option the preview didn't change...After much faffing around I found that for some reason Firefox seemed never to finish downloading the page when requesting against Visual Studio development web server; when requesting against an IIS version it worked fine. I don't know if the bug was with the Visual Studio Development server or Firefox. The result was that the script never updated. 

The second bug was with Firefox itself; if you changed  the src attribute of the script element Firefox didn't re-evaluate the element. My solution to this was to remove the script element and re-add it. Solving these issues was a right royal pain in the behind as the symptoms were the same for both bugs...

Wrapping it up

So there we go, a relatively simple thing I wanted to do took quite a while and some hair pulling because of bugs and the idiosyncrasies of working with Javascript and HTML; I dread to think of other *issues* that lie in wait using AJAX :-)

Cheers

Lee

A very funny video; a must watch :-) I'm gonna get me one of them!