Thomas

The Redesign Bug

Est. Reading Time: 4 minutes

We recently launched the Beacon site with a new design which included a handful of jQuery animation, many of which had replaced the the previous design’s Flash-intensive content. We have recently come across an issue with the jQuery library with some builds of IE7 and IE8 that resulted in an extensive trail of debugging. We concluded that it was a browser issue (even in different OS environments) that was only fixed by re-installing IE. Here I will outline the issue and the debug trail–and hopefully maybe even think up some potential fixes that weren’t explored when testing was originally performed.

The Issue

In IE7 and IE8 we found that refreshing the homepage would crash IE and sometimes handle restoring the tab, other times not.  Microsoft has acknowledged this error in an KB article.

Error Screenshots

Initial view of most common error displayed.

Error message that would periodically show right before the tab recovers.

Details of error.

Advanced error detail screen.

When tab is not recovered, this screen is shown. Had to repeatedly refresh until this error occurs.

Just-In-Time Debugger error found from a different machine.

The Debug Trail

  • Initial replication of issue in IE 8.0.6012 on one of the test machines using a Windows XP environment.
  • Attempted browser-configuration changes that might’ve caused issues including:
    • Privacy Settings
    • Security Settings
    • PrivateBrowsing
    • Add-Ons disabled
    • Just-In-Time Debugging (picked up from a slightly different error that was sent to me as a screenshot from Mark Dirks — last one on right shown above) Unfortunately not of these seemed to be the culprit.
  • Disabled JavaScript in IE altogether–which of course fixes it but not what we we’re aiming for. This confirms it is a JavaScript/jQuery related issue
  • Attempted using different versions from currently used (1.6.1) to most recently published version from jQuery site (1.6.4) – tried both compressed/uncompressed versions without any success.
  • Checked a  changelog of jQuery since version 1.6.1 onward for IE7/8 errors. *Anything related to these browsers I had checked out scripts for any instances of (CSS background-image in jQuery and other function calls)
  • One Google search led me to a site that reported changing the jQuery file name had corrected their similar mshtml.dll error—-not the case here)
  • Double checked the in-line JavaScript as well as .JS file functions dependent on the jQuery library contained no redirects or any instance of the window.location method Since the IE8 error that comes up sometimes on the test machine says the browser attempted to load more than twice) – the only instance of this I found is a comparison checking if ‘#beacon-video’ is in the URL and if so, it runs a function to scroll the Beacon video into view and sets the tabs display(css) values. The window.location value is never assigned anywhere.
  • Checked that there weren’t multiple instances of window.onload or jQuery(document).ready()
  • Ran the jQuery library file through a beautifier to get a better look at the pin-pointed trouble spot you found and checked for any obvious issues. Justin Klingman found that in the compressed library he could comment out the last half of the code which removed the crash so before ‘beautifying’ the code I had marked this position with a comment and looked in the region after the code was cleaned up.
  • Removed all other scripts from the page to see if those dependencies may have had an impact on the crash, but removing them all (including the JavaScript function calls in the body,) except for the jQuery Library. No difference, same crashing effect.
  • The only change that did successfully fixed the crashing tab to load was removing jQuery from the page, however, when the content of another root level page (the SEM pages) into the root default document, that loads/refreshes fine without crashing. The only difference between interior/homepage in terms of JavaScript is the presence of the homeScripts.js file and the inline function calls on the homepage. After further testing this, removing only homeScripts.js still crashed the tab on the homepage (unless jQuery was also removed) — All internal pages use the same copy of the jQuery Library and they don’t crash, so the exact source of what’s crashing the page/tab is still not clear to me.

10 Comments

  1. Henning Jäger
    Posted November 7, 2011 at 7:22 am | Permalink

    Hey Thomas,

    thank you very much for sharing. I found myself in exactly the same position as you are. Already tried my luck with the Microsoft Professional Support for a few weeks without succes. I hoped that they would be able to pinpoint what exactly is going wrong.

    Have you been able to test this with Internet Explorer 9? Are your crashes happening with IE9 as well?

  2. Posted November 7, 2011 at 1:57 pm | Permalink

    We tested in version IE7 and forward. We didn’t have see any instances of the issue with IE9.

  3. Posted November 8, 2011 at 3:49 am | Permalink

    Thomas

    Very interesting to those of us suffering the same problem. We provide the software solution that experiences the problem at Henning’s site so we are obviously very keen to find a solution. The only real difference that I can see is that you could repeat your problem whenever you liked, but for us it is intermittent. We have not managed to repeat it at all in the lab.

    I wondered, are you still in a position to repeat the problem at will? If so, can you say if it still exists with jQuery 1.7? Is it also the case that the unminified version rectifies the situation for previous releases?

    We upgraded from 1.6.3 to 1.6.4 and if anything it got slightly worse.

    Thanks
    Kevin

  4. Posted November 8, 2011 at 1:26 pm | Permalink

    Thanks for the response Kevin. Interestingly enough, I took your idea of upgrading to 1.7 on our development server, but when I loaded up the page prior to making changes–the issues appears to be resolved.

    Our other sites are still showing the issue occurring, so my guess is that some of the recent enhancements we’ve made must’ve had a change somewhere that fixed it. We added some changes across the entire site, the homepage (which was the only page giving the error) only had modifications within the contact form. As far as upgrading to version 1.7, I am cautious to fix whats no longer broken. I might throw it up on the dev site temporarily to see that it doesn’t break again and perhaps in a future release include the new library.

    Thanks again,
    Thomas

  5. Posted November 9, 2011 at 3:00 am | Permalink

    Oh that is a shame (the fact that we cannot test the veracity of 1.7 that is) :)

    Is it also possible, therefore, that your recent changes negate the assumption that it is automatically fixed in IE9? Or did you manage to prove that IE9 works regardless of your recent changes or jQuery release?

  6. Posted November 9, 2011 at 1:00 pm | Permalink

    I have to VPN to another machine to re-create the error (for IE8). My local machine has a copy of IE9 that came through just fine when we initially began debugging the issue.

  7. Posted November 9, 2011 at 2:30 pm | Permalink

    Update*: The issue seems to be back on dev. I’ve scrambled across recent changes to see if any recent changes would’ve made the difference. Still nothing. The only thing I can do to resolve the issue in IE8 is to remove jQuery altogether. jQuery 1.7 still doesn’t resolve it.

  8. Posted November 9, 2011 at 3:14 pm | Permalink

    I wouldn’t say I have found a fix, but a workaround at least… In the included jQuery library, you can wrap the following condition around its entirety to resolve the crash occuring in IE8.

    var allowJquery = true;
    if(navigator.appVersion.indexOf(“MSIE 8″)<0){

    //jQuery Library Here

    }else allowJquery = false;

    This removes all jQuery use from the page in IE8 and will require you to program accordingly. You can use the allowJquery variable for just this. I tested the same code on our dev server and it resolved the crashing, althought all jQuery dependent scripts fail to work (which could just be replaced with noscript contents).

  9. Posted November 12, 2011 at 4:44 pm | Permalink

    Thanks for the info. Disabling jQuery is just not an option for us unfortunately.

  10. Posted February 1, 2012 at 8:59 am | Permalink

    Version 1.7.1 appears to resolve the issue with IE8!