Towards PhantomJS 2.5

[ariya]

Going forward, what will happen in PhantomJS land:

Source Code

• Use system-installed Qt 5. This is established with pull request Be ready for bleeding edge WebKit #14386 from @vitallium.
• Use system-installed QtWebKit. Also part of the above pull request. Ideally of course this is using the latest QtWebKit (see annulen/webkit project from @annulen).
  Compared to vanilla QtWebKit of Qt 5.x, this latest QtWebKit enables lots of new modern web platform features, check Comparison with QtWebKit 5.6 for more details.

Packaging

• Remove build.py. It won't work anymore with the two above changes. Consequently, building PhantomJS will be similar to building any other Qt-based projects (qmake && make).
  We may need to supply a simple configure script and a convenient make install to make packaging easier for the distribution packagers (Debian/Ubuntu/Fedora/Nix/Homebrew/NuGet/etc). See qconf for details.
• Recreate static build packaging script #14459: Recreate static build packaging. A single executable with virtually no dependency is what makes PhantomJS very popular. This is also important to support installer wrapper such as npm's phantomjs-prebuilt for Node.js, phantomjs gem for Ruby, etc.

Features

We need to ensure that the Linux version can still operate in pure headless mode (without X11).

Regression: it won't be possible to disable web security.
#14461: Regression: there won't be support for printing headers & footers.

[ariya]

@annulen Is there any news on a distribution packager's willingness to make an official package of QtWebKit TP2 (or later releases)? How about Homebrew @MikeMcQuaid?

This becomes important as it will ensure that a future distribution-packaged PhantomJS does not deviate (get "crippled") regarding its feature sets. For instance, if a distribution contains a PhantomJS 2.5 release built using the outdated Qt 5.2 and its QtWebKit module, it will potentially confuse the users since it will not support all the latest web platform features.

[vitallium]

Reference issue: qtwebkit/qtwebkit#115

[moimael]

Any plan to port phantomjs to Qt Webengine , since now Qt WebKit will not see new features ?

[annulen]

@ariya I think it's even more important to ensure that crippled versions are not distributed at all, so users don't get confused and go straight to official release binaries.

[annulen]

@moimael Read the topic plz

[ariya]

@moimael Check this post. In all cases, feel free to start a separate discussion (this issue is focusing on our 2.5 effort).

[MikeMcQuaid]

@annulen Is there any news on a distribution packager's willingness to make an official package of QtWebKit TP2 (or later releases)? How about Homebrew @MikeMcQuaid?

@ariya We'll package it when it's a stable version but are open to having a PR open at any point.

This becomes important as it will ensure that a future distribution-packaged PhantomJS does not deviate (get "crippled") regarding its feature sets. For instance, if a distribution contains a PhantomJS 2.5 release built using the outdated Qt 5.2 and its QtWebKit module, it will potentially confuse the users since it will not support all the latest web platform features.

From a packagers perspective the best way around this would be to check for such things in your configure/CMakeLists.txt/qmake and refuse to build if you're using an outdated version. Similarly, you could consider bumping PhantomJS' version when new Qt 5 releases come out with bumped requirements to note the minimum features that are required.

[ariya]

I don't think it's always possible to prevent a modified/tweaked/crippled version of PhantomJS: take a look at Debian package https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817277.

Not having a bundled Qt/QtWebKit certainly will simplify the packager's life. That said, it won't help much if the available system Qt/QtWebKit is still outdated.

[annulen]

In Debian Stable you'll always have QtWebKit version, outdated by a couple of years