cam, 297 words, 0 comments, Javascript, Internet Explorer, Operation Aborted Error, Sitemeter

We recently had an issue in development with Internet Explorer's Operation Aborted error. It halts the loading of the page nicely [not] to the horror of developer's everywhere but since most development and debugging is done on Firefox courtesy of the exceptionally useful firebug tool it often gets missed or caught at the last moment.

The Internet Explorer javascript compiler/runtime is not always accurate in its error throwing. In fact it nearly never is, and the actual error thrown is an emergent issue relating to a deeper fault. In our case the Operation Aborted was a related error that Internet Explorer had issues with. But that is the purpose of quality control and taking the development code through strict levels of testing before publishing into production.

Sitemeter seems to have skipped that step. Websites that embedded their javascript appeared one morning on IE browsers with the Operation Aborted error. Via ReadWriteWeb:

A bug found in both the javascript and HTML widget made thousands of sites using Sitemeter inaccessible earlier today including popular blogs such as PerezHilton.com, Gizmodo, Valleywag, and Problogger. When users would visit any sites using Sitemeter, they would be presented with an error message pop-up:

Javascript is becoming the glue that enables client-side applications in browser to offer something akin to the desktop experience. Part of its appeal is that it is widely embedded in all browsers out of the box.

This also means there is a wide range of javascript runtimes that the code has to run on with all the idiosyncrasities and permutations that come with it. It can be annoying, especially in the sub-par implementations from the many versions of Internet Explorer - however - it is no excuse to get something as badly wrong as Sitemeter did. (reply)

cam, 300 words, 0 comments, Comma, Javascript, Working Life, Software Development, Javascript Lint

Sometimes a working week can be summed up into a concise and simple symbol. In the case of this week it is the comma.

Javascript is exceptionally powerful for its object literal syntax and the ability to move functions into the scope of other objects. Where once I used to complain of it giving me a black lung, now I am appreciative of its features and capabilities.

We compress out javascript down into as small a file as possible. So javascript objects which are littered across multiple modules and loaded dynamically in a development environment are compressed into just a few javascript files for production.

Browsers, especially firefox, tend to be forgiving where javascript syntax is concerned. A trailing comma in an object in firefox and safari is ok. In Internet Explorer it is not. When compressing javascript down, other issues that are fine in a raw file, such as a conditional or going across multiple lines in an if conditional, cause the page to fail as the javascript cannot be compiled by the browser's javascript runtime.

At which point it becomes a pig in a poke. Especially in large software systems with numerous teams checking in code across multiple paths, modules, packages and products. This is when the work becomes laborious and syntax checked line by line by javascript lint checkers such as jslint and javascript lint.

This week we got an operation aborted error from IE7/IE6 in our project. The issue according to Microsoft's support website was that the DOM was being manipulated before it had been loaded into the browser. It was an indirection. The issue was syntax. The lesson from this week was lint check for semi-colons, brackets and trailing commas ruthlessly in Javascript code that is going to be compressed. (reply)