We recently hit upon a weird bug. Few of our jQuery grids (rendered via the default jQuery plugin, available in Grails using <jqgrid: >) stopped loading in IE10 (please don’t say anything, we’re already sore about taking a decision to support it) when we deployed the application on the cloud (S2). Some custom functions that were used to format the grid data became undefined, even when we could see them in the page’s source code. After a lot of investigation (and several misleading guesses that each required time and effort to code-deploy-test because on our local machines everything worked fine anyways!) we figured out that the problem was the way IE loaded and executed the javascript libraries. Ideally, when you include javascript libraries to your webpages in a particular order, you’d expect them to be loaded (and executed) in the same order. However, there’s a tradeoff when it comes to serially loading the libraries and executing them in order as a particularly heavy library may obstruct the loading of other smaller ones which would essentially delay rendering of a fully functional page. The ideal order of page loading should be: Load the DOM elements. Parallely load mutually exclusive js libraries. Load libraries that are dependencies for other librariesscripts. Load the dependent libraries. (assuming that the execution would follow similar usage pattern)
The problem, in our case, cropped up when a dependent js library started executing even before the library it required (jquery-min-1.8.x) was still loading over the slow test server on the cloud. Notably, this happened only on IE10! Ironically, IE was the first browser to introduce ’defer’ to give some sort of a manual control over the loading of javascript libraries. It has been a long journey since the days of defer. HTML5 has some cool strategies to deal with this issue (which are not fully supported by all browsers atm I believe).
The fix
We tried quite a few things to fix this issue. Since the project is built on Groovy on Grails, we explored the idocyncracies of the <r:script tag as well (It does not do an in-place substitution of the enclosed scripts, it attaches the script before the end of the <body> tag. Could be quite troublesome in trying to trace an unsuspected bug I guess) but could not achieve much. Finally, all we did was to make sure that the page loading performance is improved so that we cut down the latency that was being introduced by the cloud deployment. A thorough examination and elimination of unwanted scripts got the things to work.