For those who don't care about the back-story and just want the solution: switch the user-agent to Firefox by using the WebClient constructor that takes a BrowserVersion parameter.

... One of my colleagues wrote a htmlunit test that involved swiftly navigating through a set of pages. The test checked the behaviour was correct and passed just fine, but left behind a very large number of messages like this:

runtimeError: message=
  [The data necessary to complete this operation is not yet available.]
  sourceName=[http://localhost:10821/js/jquery-1.6.1.js] line=[16]
  lineSource=[null] lineOffset=[0]

This was looking pretty nasty in the hudson and mvn build logs, so I investigated a little to see if I could get rid of it.

First step was to try to figure out what part of the jquery script was triggering the problem, but of course we are using the minified jquery script, so it was impossible to find the problem on line 16 (line 16 is jquery).

Replacing the minified script with the "source" version I get the same error reported at line 923. It's doing the following check:

// The DOM ready check for Internet Explorer
function doScrollCheck() {
 if ( jQuery.isReady ) {
  return;
 }

 try {
  // If IE is used, use the trick by Diego Perini
  // http://javascript.nwbox.com/IEContentLoaded/
     document.documentElement.doScroll("left");
 } catch(e) {
  setTimeout( doScrollCheck, 1 );
  return;
 }

 // and execute any waiting functions
 jQuery.ready();
}

Line 923 is the one inside the try block. Of course, this is a an IE specific check, and the default user-agent mimicked by HtmlUnit is Internet Explorer 7 - and yes, we were using the default.

You can change the default by passing a BrowserVersion parameter to the WebClient constructor. Switch to Firefox 3 or 3.6 and the problem goes away, switch to IE8 and it gets worse (test fails) - although it seems this is for different reasons, not related to the doScrollCheck. Can't even escape browser version troubles when not using a browser :(

Incidentally I discovered recently that many of the latest browsers and developer plugins can "unminify" javascript on the fly.

blog comments powered by Disqus