The Layout Test fast/frames/frame-src-attribute.html fails whein it is executed manually The diff between expected result and current given results is dumped bellow: --- /tmp/layout-test-results/fast/frames/frame-src-attribute-expected.txt 2010-01-08 16:10:45.304434533 -0400 +++ /tmp/layout-test-results/fast/frames/frame-src-attribute-actual.txt 2010-01-08 16:10:45.304434533 -0400 @@ -8,13 +8,13 @@ RenderView at (0,0) size 800x600 layer at (0,0) size 800x600 RenderBlock {HTML} at (0,0) size 800x600 - RenderBody {BODY} at (8,8) size 784x578 - RenderBlock {P} at (0,0) size 784x19 - RenderText {#text} at (0,0) size 616x19 - text run at (0,0) width 616: "This test checks whether a frame element's 'src' attribute is a complete, rather than relative, URL." - RenderBlock {PRE} at (0,33) size 784x19 - RenderText {#text} at (0,1) size 624x17 - text run at (0,1) width 624: "PASS: Frame 'src' attribute should include 'LayoutTests/fast/frames' and does." + RenderBody {BODY} at (8,8) size 784x579 + RenderBlock {P} at (0,0) size 784x20 + RenderText {#text} at (0,0) size 679x20 + text run at (0,0) width 679: "This test checks whether a frame element's 'src' attribute is a complete, rather than relative, URL." + RenderBlock {PRE} at (0,36) size 784x16 + RenderText {#text} at (0,0) size 456x16 + text run at (0,0) width 456: "PASS: Frame 'src' attribute should include 'LayoutTests/fast/frames' and does." RenderFrame {FRAME} at (0,0) size 0x0 layer at (0,0) size 8x8 RenderView at (0,0) size 0x0
diego, something you have to be sure of is if it is failings locally in your machine, or the buildbot would fail while running it manually. the diff you pasted shows a tiny differences probably caused by the font size issues we've been seeing: the buildbot has different version of fontconfig and friends that cause tests to fail on newer ubuntu versions, for example. ossy, could you verify if they pass on the buildbot box, if ran manually
I verified this test, it fails on buildbot too. (with similar diff) But unfortunately it is a more complicated bug ... In my opinion it is causeless to use rendertree dump for this test, we should refactor this test to dumpAsText type, because comparing pixel differences for this is absolutely nonsense. I've found a strange bug around this test. If we only examine rendertree dump (aside from pixel differences), we should say it passed. But with QtLauncher we can't see the necessary PASS string is written by JS into pre block. It is very strange ...
This bug is not reproducible at r79447
Reopening to make sure.
=== Bulk closing of Qt bugs === If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary. If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.