!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" }}} 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 on these two topics extensively discussed on the mailing list. * [http://lists.webkit.org/pipermail/webkit-efl/2012-November/000433.html How to run layout tests with ATI and NVidia drivers] * [http://lists.webkit.org/pipermail/webkit-efl/2012-November/000434.html 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 /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=" 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).