PhantomJS freezes on nontrivial number of resources
jart opened this issue · comments
I'm adding PhantomJS test rules to Bazel. I'm using PhantomJS version 2.1.1 and am attempting to automate Closure Library unit tests in "raw sources" mode. A hello world test causes twenty <script src="..."> tags to be appended to the document, which are expected to execute serially.
For the hello world test, I'm noticing 62% flakiness. The PhantomJS page gets stuck while loading a random one of those resources and the window.onload and onLoadFinished callbacks are never called.
Setting page.settings.resourceTimeout = 1000 allows the test to reach the failure state. But this isn't a viable workaround because it'd take ten test runs to go down to 0.1% flakiness. I also suspect flakiness will increase for normal apps that can load hundreds of source files.
I'm using the built in PhantomJS webserver to serve these runfiles. But I don't suspect that's the root cause because people in #10652 report the same problem when using Apache.
I would like to see this issue solved, because raw sources mode offers better stacktraces. It also allows tests to run much faster, since they don't have to be compiled. This significantly improves the developer experience.
What's the simplest test case that we can run to reproduce the problem?
Try this one out:
var page = require('webpage').create();
var server = require('webserver').create();
server.listen(31337, function(request, response) {
var data = '';
var contentType;
if (request.url == '/index.html') {
contentType = 'text/html;charset=utf-8';
data += '<!doctype html>\n';
data += '<title>oh my goth</title>\n';
data += '<body></body>\n';
for (var i = 0; i < 100; i++) {
data += '<script src="/s' + i + '.js"></script>\n';
}
data += '<script>window.callPhantom(true);</script>\n';
} else {
contentType = 'application/javascript;charset=utf-8';
var n = parseInt(request.url.match(/\d+/)[0]);
if (n > 0) {
// call function defined by previously loaded script
data += 'f' + (n - 1) + '();\n';
}
data += 'function f' + n + '() {\n';
data += ' console.log("hello ' + request.url + '");\n';
data += '}\n';
}
response.writeHead(200, {
'Cache': 'no-cache',
'Content-Type': contentType
});
response.write(data);
response.close();
});
page.onConsoleMessage = function(message) {
console.log('-> ' + message);
};
page.onCallback = function() {
phantom.exit();
};
//page.settings.resourceTimeout = 2000;
page.open('http://localhost:31337/index.html');Thanks for the test case. I think we need to identify whether this is cause by the embedded web server or PhantomJS itself. The embedded web server (based on Mongoose) is known to be a bit flaky (not Mongoose in particular, but the binding and the interplay).
Hey @ariya I want to share with you the project we're launching that makes awesome use of PhantomJS: https://github.com/bazelbuild/rules_closure (see specifically closure_js_test)
Is there any update on this issue? Having this fixed would allow us to improve the developer experience of our JavaScript build system by quite a bit. Also is there anything I can possibly do to help?
@ariya I can confirm that I'm seeing this issue (or something that seems very much like it) when using the serve-static middleware, which is solid as a rock when I visit the url in a normal browser.
I'm trying to render a page with quite a few external resources (4 CSS files, 2 JS files and ~80 images) and it fails about one in ten times (the page.open() callback is never called). Any idea why this might be happening? I presume it's related to #10652...
Thanks!
For me it flip flops with rate around 20%, i.e. 20% times it hangs. Around 20-30 external resources are loaded during page rendering. But what is more important, it usually hangs during first page load, i.e. you load the page, you submit the form and phantom hangs. If it didn't hang during this one, it will likely not till the end of the test, despite the pages complexity in further.
Also I cannot reproduce this issue locally ( MacOS ), but it constantly reproduced remotely ( Ubuntu )
Maybe this information will help to pin this one.
Due to our very limited maintenance capacity, we need to prioritize our development focus on other tasks. Therefore, this issue will be automatically closed (see #15395 for more details). In the future, if we see the need to attend to this issue again, then it will be reopened. Thank you for your contribution!