DumpRenderTree is related to WebKit's layout tests and can be run with the run-webkit-tests script.

Dependencies

You will need to install the following Debian packages to run WebKitEFL layout tests.

• apache2
• libapache2-mod-php5
• libruby
• xvfb
• gstreamer-dbus-media-service

sudo apt-get install apache2 libapache2-mod-php5 libruby xvfb gstreamer-dbus-media-service

Building DumpRenderTree

In order to build it in a way that all expected tests pass and it does not crash, however, certain features need to be enabled when building the port. SHARED_CORE currently needs to be turned on, and some features need to be enabled manually.

./Tools/Scripts/build-webkit --efl --cmakearg="-DSHARED_CORE=ON" --update-efl

Alternatively, set ENABLE_DRT=1 in your environment to enable the SHARED_CORE define during the build process.

Running LayoutTest

In order to run WebKitEFL's LayoutTest successfully, "exit-after-n-failuers" option should have 500 as its own value when user run layout test because at least 500 test cases are failed for now.

./Tools/Scripts/run-webkit-tests --efl --release --no-show-results \
                                 --results-directory layout-test-results \
                                 --exit-after-n-failures 500 --verbose

If you wish to run a single test you can do:

./Tools/Scripts/run-webkit-tests --efl fast/forms/plaintext-mode-1.html

If you want to test WebKit2EFL instead of WebKitEFL, add "-2" option.

./Tools/Scripts/run-webkit-tests --efl --release -2

Known issues

If all your tests are crashing, you might want to have a look at these two topics extensively discussed on the mailing list.

• ​How to run layout tests with ATI and NVidia drivers
• ​How to run layout tests with X server 1.13.0 (i.e. the X server shipped on Ubuntu 12.10)

Debugging crashes

It is possible to run gdb directly on the DumpRenderTree binary to debug crashing tests:

$ gdb --args <BUILD DIRECTORY>/bin/DumpRenderTree LayoutTests/fast/forms/plaintext-mode-1.html

In WebKit2, the UI process will spawn new Web processes so it can be tricky to debug those with gdb. If you need to debug a crash in a WebProcess, you can use the "-webprocess-cmd-prefix=<prefix>" argument to run-webkit-tests (in debug mode only). For example, if you want the new Web processes to be executed in gdb, you can use the following command:

./Tools/Scripts/run-webkit-tests -2 --efl --webprocess-cmd-prefix="DISPLAY=:0 xterm -title WebProcess -e gdb --args" LayoutTests/fast/forms/plaintext-mode-1.html

The "xterm" is necessary or gdb will run in the current terminal, which can get particularly confusing since it's running in the background, and if you're also running the main process in gdb, won't work at all (the two instances will fight over the terminal). The DISPLAY=:0 is necessary since the xterm goes to the Xvfb otherwise.

To auto-start the web processes in the debugger, send the "run" command to the debugger:

./Tools/Scripts/run-webkit-tests -2 --efl --webprocess-cmd-prefix="DISPLAY=:0 xterm -title WebProcess -e gdb --eval-command=run --args" LayoutTests/fast/forms/plaintext-mode-1.html

If you want to do the same thing when executing the EFL MiniBrowser, you can do it by properly setting the "WEB_PROCESS_CMD_PREFIX" environment variable:

WEB_PROCESS_CMD_PREFIX="xterm -title WebProcess -e gdb --args" WebKitBuild/Debug/bin/MiniBrowser

Use PLUGIN_PROCESS_COMMAND_PREFIX in a similar manner for plugin process debugging (you may also have to use MOZ_PLUGIN_PATH to make sure the plugins you test are found).