Debugging Javascript in IE when you don’t control the page

So everything works great from your dev server, but once deployed, a script problem is discovered. Even worse, it only happens in IE.

Something that worked for me was to install Fiddler for .Net 2.0. There’s a nice walkthrough WMV video (why do voices in walkthrough videos all sound like the famous Ruby one?). The video doesn’t say much that one couldn’t figure out from the UI, with one exception: The black bar at the lower right for setting breakpoint patterns. For example, enter “bpu” followed by a space and some substring of the filename you’d like to break on. (If “Capturing” isn’t already showing in the bottom left status bar, click there and it will begin recording.) When one visits the page of interest, Fiddler will suspend the network request and flash in the taskbar. A red ‘T‘ will show in the left panel for the breakpointed resource, and a red box will show in the right panel. Click on the yellow ‘Break on Response’ button, and if it shows “response is encoded” below that, double-click on that message. You should see a ‘Text View’ tab; click on it. Edit the resource as you like, and then click the green ‘Run to completion’ button. Note that Fiddler breakpoints even if the file is already in cache!

This allows for inserting JS alerts and such, but it seems it could also allow one to insert a script tag for FirebugLite, and then you’d be able to debug after page load, too.

The particular problem this helped with was: Our rich text editor (RTE) wouldn’t allow one to type in it (after the page load and as long as the page was in view). This usually happened only after the cache had been cleared. This pointed to a timing issue, and sure enough, the problem was that the RTE’s iframe wasn’t complete before we tried to enable design mode on it. This is the same issue I blogged about with IE’s createStyleSheet method, but in this case there was no script error indicated. Our code to handle this case had a typo in it — I had spelled “onreadystatechange” as “onReadyStateChange” as O’Reilly’s Dynamic HTML: The Definitive Reference spells it, which is a typographic convention for highlighting the words within handler names that will cause you grief if you follow the spelling literally. Use all lowercase!

Print Friendly, PDF & Email