Be ready for bleeding edge WebKit

[vitallium]

These commits are part of my preparation to move to a brand new WebKit.

What's inside:

• new Webkit. New features. Comparison with current version
• no support for printing headers/footers (not planned)
• no support for toggling web security (planned)
• ability to use (and build) phantomjs against system Qt

[zackw]

If one were to want to give this a test drive, how would one build it? build.py won't work with qtbase and qtwebkit removed.

(I'll accept "don't even try just yet" as an answer ;-) )

[vitallium]

@zackw I'll write instructions a bit later. This is not the final pull request. But basically, now you just need to build a new WebKit and make install to your Qt installation. That's all.

And yes! You can try it now! I successfully built PhantomJS for all 3 platforms (there is no static build yet).

UPD
If you want to test drive it now, you can grab TP2 binaries, copy them to your Qt SDK and use.
More info here: https://lists.webkit.org/pipermail/webkit-qt/2016-June/004063.html

[annulen]

I think it would be great to integrate headers and footers printing, but first I'd like to see that code at https://codereview.qt-project.org/#/ for proper API review

[vitallium]

Static build ref: qtwebkit/qtwebkit@298894e

[vitallium]

Just a quick question: do we really need static build of PhantomJS?

I mean if we are going to use other Qt libraries (positioning, sensors, etc.), I think we don't need static build at all. Yes, it's convenient to have just one executable. But shared build has its pluses too.
If shared build is okay, then we already ready to merge this pull request and make users drop their jaws.

/cc @ariya @zackw @JamesMGreene

[annulen]

Playing devil's advocate: static build usefulness does not depend on how many Qt modules you are using, it's about exclusion of unused parts of library code from resulting binary. It makes perfect sense until you start shipping multiple applications linking to the same Qt or QtWebKit, or introduce C++ plugin system where plugins have to link to that libraries

[ariya]

What shall we do regarding printing of headers/footers?

[ariya]

A single executable on Windows and OS X has been always a selling-point for PhantomJS (ease of install).

On Linux however, static build was historically needed because slow Qt 4.x progress. With the latest Qt 5.6 being packaged quickly by major distributions, the need becomes less and less.

On the other hand, what do we do with the npm phantomjs-prebuilt? I can imagine that lacking a static build (particularly on Linux) will cause a bit of push back/confusions there.

[vitallium]

What shall we do regarding printing of headers/footers?

I am thinking about dropping this feature at all. I don't think most users need it. And this feature requires additional changes in QtWebKit.

A single executable on Windows and OS X has been always a selling-point for PhantomJS (ease of install).

Agree. "Plug&Play" feature is a really crucial point of PhantomJS. My view on this is we can bring the single executable file back in future.

[ariya]

I'll squash and merge this. Further discussion can happen in #14458.

[ariya]

Merged. Thanks @vitallium!

[willemmulder]

PhantomJS is used by quite a few people to generate PDF documents with headers and footers, so support for headers and footers is actually quite important for those people. I agree that is not the primary use-case, but support (or at least a workaround) would be great!

[pofider]

I addition to @willemmulder comment - headers/footers are great advantage over electron based pdf printing where it is not supported. Wkhtmltopdf can do headers, but it doesn't have low latency as reusing phantomjs instance. This is why phantomjs rocks as the best tool for pdf generation and it would be great to find a solution to keep this feature.

[therealsamlin]

I believe we can get around footers & headers with JS?

[willemmulder]

@samlinbris If that is so, that would be great! How would that work?