Backported fix to 3.3 EE branch at revision 40412.

Reverting to jQuery 1.7 in the 3.3 EE branch was desirable and feasible, since it improves dramatically performance on IE8 browsers, without affecting the performance of other browsers. Moreover, QA reports that the failures seen after reverting to jQuery 1.7 in the customer branch, were fixed by simply updating the selenium scripts. So, no new real bugs were introduced by this change.

After doing an extensive binary search of previous revisions, it was found that the stop script error message started to appear after the ICE-9274 fix in May of last year. However, in revisions just before that fix, the performance on IE8 was just as bad. That fix simply made the problem more evident. Eventually, the approach of ICE-9274 was replaced by a better approach in ICE-9520.

I went further back in revisions and noticed a dramatic degradation in performance in IE8 right after upgrading to jQuery 1.9.1 (ICE-8920) in February of last year. The performance degradation was not only caused by the new jQuery version, but by some changes in the data table javascript. At the end, the problem was caused by the use of the jQuery.find(selector) function, which is odd, since jQuery.find() is supposed to have better performance.

In the end, what solved the performance issues in the Williams branch was 1) applying ICE-9520 to it, 2) reverting to the previous version of jQuery (1.7), and 3) changing the occurrences of jQuery.find(selector) for ice.ace.jq(selector) and moving the selectors from the prototype to object properties.

Using the 3.2 release jars and testing on the POC, I could see that there was no issue and the rows are retrieved fairly fast.

Using the 3.3 release, I could see that retrieving the rows actually takes longer than it takes now, but the stop script message doesn't appear.

I reverted to revision 38615 in the tableConfigEnh branch, which is the very revision when that branch was created, and I tried to reproduce the issue with that code. The issue was still reproducible in the same way. So, it seems that this performance issue on ie8 is not related to the work related to ICE-9471, but to earlier fixes targeted for ICEfaces 3.3.

Further testing revealed that the issue is reproducible with the build from November the first, 2013. Most likely, general changes related to ICE-9471 caused this situation.

There doesn't seem to be a single point of failure. I simplified the jQuery selector used to access the row, and it improved things, but if the number of rows was increased, the stop script message appeared again.