Regression from #12431: the loop to clear all surviving pages
neglects to check for entries in `m_pages` which have already
been closed, fully destructed, and therefore replaced by NULL
pointers.
This code:
console.log("Hello World!");
phantom.exit();
console.log("Meh, noone should see me!");
currently produces this unexpected output:
Hello World!
Meh, noone should see me!
This patch fixes it to only output the first line, by loading a blank
page on phantom.exit(). Direct deletion of the web page can trigger
crashes, so this is a safe workaround.
https://github.com/ariya/phantomjs/issues/12431
The newer ConsoleReporter is very quiet by default, which is nice, but
this provides a way to get something more like the older one-line-per-test
output.
#12230 (Test suite improvements).
* Anything on the command line after "run-tests.sh" will be understood
as a regular expression (if there is more than one argument, they are
concatenated, with spaces in between) and only the tests whose "full
names" match that regexp will be run. The full name of a test is the
"describe" string plus a space plus the "it" string. Note well that,
unlike the test-runner output, there is no colon in there.
* run-tests.sh and run-tests.js now correctly handle being invoked from
an arbitrary directory; the cwd does not have to be the project root.
* Shell portability fixes for run-tests.sh.
#12230 (Test suite improvements).
The new Jasmine includes a version of this formerly external add-on, but it
is buggy and doesn't print details of failing tests.
#12230 (Test suite improvements).
The newer jasmine-console behavior requires minor adjustments to the
ConsoleReporter we create in run-tests.js. Also, en passant fix for
a bug in the final callback: exiting with status equal to the number
of failed tests does not work, because the _exit() system call takes
only the low eight bits of the value passed. If a test run happened
to have 256 failing tests, the old code would have spuriously exited
successfully. Instead, just exit(1) if any tests fail.
#12230 (Test suite improvements).
Three tests were (potentially) dumping text to console.log during the
run, which they should never do.
Fixing that revealed that one of them, the test for interrupting a
long-running JS script, was not actually testing what it was supposed
to test. Fixing *that* revealed that the long-running-script hook is
broken and does not actually interrupt JS infinite loops; that test
has been temporarily disabled.
#12230 (Test suite improvements).
Two tests were spuriously failing because they tried to load pages on
`github.com` that were no longer structured as expected. Use a local
webserver instead.
#12230 (Test suite improvements).
The PhantomJS QPA hardcoded usage of QFontconfigDatabase on
Unix-not-OSX, causing build failures in "bundle all the libraries" mode.
Use QGenericUnixFontDatabase instead, which is QFontconfigDatabase if
fontconfig is enabled, and QBasicFontDatabase if it isn't. This means
that the bundled-qtdeps build will use only the fonts bundled with Qt,
and won't be able to find them on a machine that doesn't have the source
tree, which is suboptimal, but at least this makes the bundled-qtdeps
build complete successfully again.
Part of issue #12467.
In this mode, system-provided libraries will be used for all of
Qt's dependencies, but Qt and QtWebkit themselves are still the
bundled copies. This mode actually works.
Now that this mode exists, disable fontconfig in the "everything
bundled" mode, because it drags in the system freetype and several
other system libraries. (There is no bundled fontconfig.)
Part of issue #12467.
This is how we arrange for QtWebkit to use QtBase's bundled copy of
sqlite; without it, QtWebkit will attempt to use a system-provided
library instead, and if headers are unavailable, the build will fail.
Part of issue #12467.
As with the system-qtwebkit option, this does not actually work at this
point, but it enables experimentation toward getting it to work.
Part of issue #12467.
* build.sh now handles building qt and qtwebkit.
* preconfig.sh is now only responsible for accumulating arguments
to pass to qt's configure script.
* preconfig.sh doesn't have command line arguments of its own;
anything on its command line will be passed directly to qt's
configure script.
* first pass of adjustments to the qt configure parameters
to try to get a more static build - unfortunately, system
sqlite, libz, libpng, and libexpat are still getting pulled
in somehow (mostly via fontconfig, I think).
Part of issue #12467.
Invoking build.sh with --system-qtwebkit will skip the build of Qt and
QtWebkit and use the qmake in $PATH to build PhantomJS proper.
This doesn't actually *work* at the moment because the bundled
copy of Webkit has patches not yet merged upstream, but it's still
useful to have for testing purposes.
Part of issue #12467.
* Allow any patchlevel of Qt 5.3.x.
* Do it in the master .pro file instead of main.cpp; this makes the build
fail immediately rather than after compiling a bunch of stuff.
Part of issue #12467.
* Ignore src/phantomjs_plugin_import.cpp, which is now created during
the build.
* Add leading slashes to a bunch of files that should not be ignored if
they crop up in subdirectories.
Part of issue #12467.
window.callPhantom formerly used Array.prototype.splice for cloning
its arguments to the internal _phantom.call. This relied on
non-standard behaviour of the splice method when only a single
argument was passed to it (it requires 2 arguments).
The correct method for cloning the arguments array is to use
Array.prototype.slice, which accepts a single argument (index) and
returns a new array from the specified index.
https://github.com/ariya/phantomjs/issues/12306
Currently, the build script will continue to try to build PhantomJS
even when either QtBase or QtWebKit failed to compile. In such a
case, the script should return early and emit an error message.
https://github.com/ariya/phantomjs/issues/12433
Marcel Duran