Our company wants to start triggering our QUnit unit tests through our CI server and are looking at PhantomJS as a means of achieving this goal. We started by just trying to open a couple of our QUnit test pages in phantom via the following script:
var page = require('webpage').create();
var args = require('system').args;
page.onConsoleMessage = function(msg, lineNum, sourceId) {
console.log('CONSOLE: ' + msg + ' (from line #' + lineNum + ' in "' + sourceId + '")');
};
page.onError = function(msg, trace) {
var msgStack = ['ERROR: ' + msg];
if (trace) {
msgStack.push('TRACE:');
trace.forEach(function(t) {
msgStack.push(' -> ' + t.file + ': ' + t.line + (t.function ? ' (in function "' + t.function + '")' : ''));
});
}
console.error(msgStack.join('\n'));
};
page.open(args[1], function(status) {
phantom.exit();
});
Nothing fancy, almost copied verbatim from the phantomJS reference pages. But alas, this sometimes results in the following output:
ERROR: SyntaxError: Parse error
TRACE:
ERROR: SyntaxError: Parse error
TRACE:
ERROR: SyntaxError: Parse error
TRACE:
ERROR: SyntaxError: Parse error
TRACE:
I've dug into it and the "parse error" is because PhantomJS thinks that the jQuery variable is uninitialized, but the thing is, the pages I am trying to load in PhantomJS work perfectly fine in Chrome, IE, and Firefox, so there is no parse error that I can see (the code to load jQuery is a boring SCRIPT tag at the top of the HEAD tag, so nothing exciting there).
If it makes any difference, our tests are inside ASP.NET (aspx) pages, served through either the VS2010 built in development server, IIS8 Express, or IIS 6. My next step is to turn them into pure HTML to see if phantom will still complain, but that's not really a valid solution since loading up ASPX pages will be a requirement further down the line (to potentially do automated UI tests using Phantom).
Any ideas on what is wrong? Not sure what other pieces of information would be useful to debug this problem, but I will provide them as requested. I am stumped (especially since "parse error" isn't exactly the most useful of error messages).
Edit: This seems to be related to the following two WebKit issues:
If I turn off GZIP compression on our server it seems to work okay, but I still have to do further research into the issue.