Day: December 23, 2009

For all our applications we use pretty much the defacto standards. For us DWR is also a defacto standard for doing AJAX with a JEE backend. Like many of our applications we can’t dictate what type of browser the customer should use, so we have to check all browsers. So during the last sprint we checked it on all versions of ie, no problems. We deployed and one of our main testers create a defect ticket.

In the ticket he described the application as always creating alerts with the description call count is not a number . He used ie7, you would expect this from ie6 but not from ie7. However off course other users with ie7 didn’t have this issue. After some googling this seemed related to DWR, however we couldn’t really find the cause for the problem. However we did find a workaround for the issue.

We added this small piece of code

<script type=”text/javascript”>
$(document).ready(function(){
function errH(msg){}

dwr.engine.setErrorHandler(errH);
dwr.engine.setWarningHandler(errH);
});
</script>

This might not be the best solution, but after losing quite some time this was the preferred solution

The application I work on is accessed from all over the world, we don’t have any control over what kind of browser access it. So we have to check pretty much all possible combinations. After our latest release we had trouble with some users who were running windows 2000 with internet explorer 6.

I know this is an old system, but we can’t force them to upgrade, neither can we force them to install a real browser (i.e. firefox) as they don’t have local admin accounts. I checked windows xp with ie6 and this worked without any problems. So I picked up a windows 2000 cd and installed it in a vm. I upgraded the browser to the same version as the customer but couldn’t reproduce the problem.

After some emailing and friendly help from their local IT sysadmins, I could access an identical vm on their local systems. I user our test environment to do some tests changing settings here and there. After a couple of minutes I found out that the problem had to do with the jquery library. So I tried accessing it with the actual URL, maybe there was a security constraint or something but this worked without any problem. Even stranger when I accessed the applicaiton again everything worked perfectly, normally after the login the page would freeze and you had to kill the iexplore process.

After a while I figured it out. To shrink the size of the html we were using the compression options of apache. This shrinked the actual html sometimes with 80%. However we also shrinked all javascript libraries. JQuery default ships with a minimized library. It seems that some internet explorer versions have problems with accessing this file. I imagine that ie6 can’t handle a file that is minimized file and gziped at the same time.

So any one out there experiencing the same problems, you can check if you didn’t run into the same problem as we did.