The html5lib/runner.html layout test is failing on EFL and GTK after r143804. http://trac.webkit.org/changeset/143804 One of the tests in domjs-unsafe.dat is failing after the runner switches to writing tests into the testing iframe through setting a data: URL as the iframe's src attribute. I'll go out on a limb and say that this is failing due to some behavioral difference in libsoup, most likely in encoding the data: URL. Diff: --- /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/html5lib/runner-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/html5lib/runner-actual.txt @@ -180,38 +180,15 @@ resources/doctype01.dat: PASS -resources/domjs-unsafe.dat: PASS +resources/domjs-unsafe.dat: +4 +5 +6 +7 +8 +15 +16 +17 -resources/entities01.dat: PASS - -resources/entities02.dat: PASS - -resources/html5test-com.dat: PASS - -resources/inbody01.dat: PASS - -resources/isindex.dat: PASS - -resources/pending-spec-changes-plain-text-unsafe.dat: PASS - -resources/pending-spec-changes.dat: PASS - -resources/plain-text-unsafe.dat: PASS - -resources/scriptdata01.dat: PASS - -resources/scripted/adoption01.dat: PASS - -resources/scripted/ark.dat: PASS - -resources/scripted/webkit01.dat: PASS - -resources/tables01.dat: PASS - -resources/tests_innerHTML_1.dat: PASS - -resources/tricky01.dat: PASS - -resources/webkit01.dat: PASS - -resources/webkit02.dat: PASS +Test 4 of 49 in resources/domjs-unsafe.dat failed. Input: +<script>a='
I'm glad we started testing the data: path. :)
The following tests are showing similar symptoms after r144032: html5lib/generated/run-domjs-unsafe-data.html html5lib/generated/run-pending-spec-changes-plain-text-unsafe-data.html html5lib/generated/run-plain-text-unsafe-data.html http://trac.webkit.org/changeset/144032 http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&tests=html5lib%2Fgenerated%2Frun-domjs-unsafe-data.html%2Chtml5lib%2Fgenerated%2Frun-pending-spec-changes-plain-text-unsafe-data.html%2Chtml5lib%2Fgenerated%2Frun-plain-text-unsafe-data.html Will point failure expectations to this bug.
Hopefully the split will make it much easier to see the exact failures.
The problem appear to be various null characters in test cases. When piping the data through normal libsoup resource request process, the input data correctly encodes these characters as %00, yet libsoup returns data decoded, meaning the data gets chopped off at the first '\0' character. Looking at the html5lib/generated/run-domjs-unsafe-data.html test case, it seems that the \0 character should be replaced with the U+FFFD replacement character. Just a guess though, I'll have to run this by people more familiar with libsoup.
The HTML Parser converts null characters to the replacement character, yes: http://trac.webkit.org/browser/trunk/Source/WebCore/html/parser/InputStreamPreprocessor.h#L85
It's also possible that something other than the networking library (like encodeURICompenent) is differnet on gtk? http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/resources/runner.js#L196
No, I'm pretty convinced this is a bug in libsoup. When (for instance) the html5lib/resources/domjs-unsafe.dat is fetched via HTTP (as done when running html5lib/generated/run-domjs-unsafe-write.html) libsoup returns complete file contents, including null bytes. These tests fail due to loading single test cases through an encoded data: URL. There's nothing wrong with the encoded URL, but libsoup returns only the decoded data up to the first null byte. I'll report this upstream where the fix will most likely be done as well.
This is now fixed in upstream libsoup: https://git.gnome.org/browse/libsoup/commit/?id=c1c58c9fc79562b0da4ceeeb3fc378407f8b9c85 I'll update the libsoup versions used by EFL and GTK via Jhbuild when possible and remove failure expectations as well.
Expected to fail, but passed: (20) html5lib/generated/run-domjs-unsafe-data.html html5lib/generated/run-pending-spec-changes-plain-text-unsafe-data.html html5lib/generated/run-plain-text-unsafe-data.html The above test cases are working well on EFL. We need to close this bug.
EFL had its libsoup dep bumped in r148506, GTK I think some time before that. http://trac.webkit.org/changeset/148506 Closing this bug.