PhantomJS 1.5, Ghost Flower, was released on March 20, 2012. This version is backward compatible with version 1.4. Existing scripts should work without any modification, unless there is a need to run Flash or other plugins (see below).
PyPhantomJS, the implementation of PhantomJS in Python with PyQt, ceased the development (issue 344) and thus the code has been removed from the repository.
Pure headless (no X11) on Linux
While it’s always possible to customize the build of PhantomJS Linux without X11 (in particular since the last 1.4 release), it’s a tedious adventure. Beginning from this release, X11-less setup is the standard when building PhantomJS Linux from source.
The benefits of pure headless are two-fold: no need to use Xvfb, it also compiles out-of-the-box on a barebone Linux server without GUI. This should make it easy to place PhantomJS in various continuous integration systems and cloud/elastic platforms.
Note that the pure headless mode does not compromise the functionalities and rendering quality. For screen capture, text rasterization is still done through FreeType and Fontconfig. Various formats (PNG, GIF, JPEG) for inlined images are still supported. Even producing PDF from the web page works just fine.
No more support for Flash and other plugins
Plugin support has been completely disabled (see issue 413) for the following reasons:
Future reported issues and bugs which relate to Flash and other plugins will be marked as WontFix.
Improved troubleshooting
To facilitates easier troubleshooting, there exists support for interactive mode (REPL), remote debugging, and error handling.
If PhantomJS is launched without any argument, it starts in the so-called interactive mode, also known for REPL (read-eval-print-loop). This mode allows a faster cycle of experiment and script prototyping. PhantomJS REPL supports the expected features: command editing, persistent history, and autocomplete (with Tab key).
Terminal line editing feature of this interactive mode is based on Linenoise (an improved fork of the original project).
Remote debugging permits inspection of the script and web page via another WebKit-based browser (Safari and Chrome). This is achieved by launching PhantomJS with the new option, as in this example
phantomjs --remote-debugger-port=9000 test.js
After than, open Safari/Chrome and go to the http://ipaddress:9000. The browser will show the familiar Web Inspector interface which in this case works on the script being tested.
Note: As of now, remote debugging is only for Linux (see issue 430).
To easily catch an error occured in a web page, whether it is a syntax error or other thrown exception, an onError handler for the WebPage object has been added. An example on such a handler is:
page.onError = function (msg, trace) {
console.log(msg);
trace.forEach(function(item) {
console.log(' ', item.file, ':', item.line);
})
}
Now if the page opens a site with some JavaScript? exceptions, a detailed information (including the stack trace) will be printed out.
Note: Further refinement to the stack trace is still being planned (see issue 166).
System module
A set of functions to access system-level functionalities is available, modelled after CommonJS System proposal.
To start using, it needs to be instantiated via the system module such as:
var system = require('system');
Read-only properties:
Query functions:
An example printenv.js demonstrates the same functionality as in the Unix printenv utility:
var system = require('system'),
env = system.env,
key;
for (key in env) {
if (env.hasOwnProperty(key)) {
console.log(key + '=' + env[key]);
}
}
phantom.exit();
An example arguments.js prints all the command-line arguments:
var system = require('system');
if (system.args.length === 1) {
console.log('Try to pass some args when invoking this script!');
} else {
system.args.forEach(function (arg, i) {
console.log(i + ': ' + arg);
});
}
phantom.exit();
If the script is invoked:
phantomjs arguments.js answer 42
gives the following result:
0: arguments.js 1: answer 2: 42
Control web security
Performing cross-domain XHR is often necessary for some scripting purposes. This is now possible by disabling web security (issue 28), either with –web-security=no command-line option or webSecurityEnabled page setting.
Note: Disabling web security may make the system more vulnerable to attacks and other malicious content. Use it with great caution.
An example findads.js uses disabled web security to access the frame content from Google Ads server: https://gist.github.com/2037945.
New features
Bug fixes
Back to all releases.