After http://trac.webkit.org/changeset/113520 fast/transforms/scrollIntoView-transformed.html started to fail on Qt platforms with the following diff: --- /ramdisk/qt-linux-64-release/build/layout-test-results/fast/transforms/scrollIntoView-transformed-expected.txt +++ /ramdisk/qt-linux-64-release/build/layout-test-results/fast/transforms/scrollIntoView-transformed-actual.txt @@ -20,5 +20,5 @@ PASS - Element a and Element b had different scrollTop PASS - Element b had scrollTop: 0 -PASS - Element c and Element d had same scrollTop +FAIL - Element c and Element d had different scrollTop
I skipped it - http://trac.webkit.org/changeset/113545 Please unskip it with the proper fix.
Created attachment 143619 [details] Subset of the layout test showing a render issue (different results on WebKit and Firefox)
Created attachment 143620 [details] Attached HTML file rendered on Firefox
Created attachment 143621 [details] Attached HTML file rendered on WebKit
The intent of this test is to make sure scrollIntoView(false) scrolls the bottom of an element into view in the presence of a scaling transform. One way to test it without hardcoding numbers into the test, is to put an element at the bottom of a scrollable area and check that scrollIntoView(true) and scrollIntoView(false) return the same value -- which they should due to clamping. Looking at those images, one guess is that on Qt margins/padding may be causing an issue here. Try removing them in the CSS.
webkit-dev thread about the scrollIntoView issue that affect this layout test: http://lists.webkit.org/pipermail/webkit-dev/2012-May/020805.html
(In reply to comment #5) > The intent of this test is to make sure scrollIntoView(false) scrolls the bottom of an element into view in the presence of a scaling transform. One way to test it without hardcoding numbers into the test, is to put an element at the bottom of a scrollable area and check that scrollIntoView(true) and scrollIntoView(false) return the same value -- which they should due to clamping. > > Looking at those images, one guess is that on Qt margins/padding may be causing an issue here. Try removing them in the CSS. Hi, The images are about a indirect issue related to this bug, BTW I don't think Qt has a role into the final render result, the screenshot was taken on Chromium installed on my system, but it's the same on Qt5 MiniBrowser as well.
For some reason, this test passes on Chromium DumpRenderTree though. As the issue seems mostly unrelated to the intent of the test (prior to the bugfix in 83385, half of the text paragraph would be cut off), whatever CSS tweak needed to fix this test fail seems fine to me.
It passes now, unskipped by r130738
It isn't in the skipped list now.