RESOLVED FIXED 83419
[Qt] REGRESSION(r113520): fast/transforms/scrollIntoView-transformed.html fails 
https://bugs.webkit.org/show_bug.cgi?id=83419
Summary [Qt] REGRESSION(r113520): fast/transforms/scrollIntoView-transformed.html fails
Csaba Osztrogonác
Reported 2012-04-07 06:07:23 PDT
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
Attachments
Subset of the layout test showing a render issue (different results on WebKit and Firefox) (832 bytes, text/html)
2012-05-23 12:34 PDT, Hugo Parente Lima 		no flags
Details
Attached HTML file rendered on Firefox (4.32 KB, image/png)
2012-05-23 12:35 PDT, Hugo Parente Lima 		no flags
Details
Attached HTML file rendered on WebKit (4.07 KB, image/png)
2012-05-23 12:36 PDT, Hugo Parente Lima 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Csaba Osztrogonác
Comment 1 2012-04-07 06:14:40 PDT
I skipped it - http://trac.webkit.org/changeset/113545 Please unskip it with the proper fix.
Hugo Parente Lima
Comment 2 2012-05-23 12:34:54 PDT
Created attachment 143619 [details] Subset of the layout test showing a render issue (different results on WebKit and Firefox)
Hugo Parente Lima
Comment 3 2012-05-23 12:35:30 PDT
Created attachment 143620 [details] Attached HTML file rendered on Firefox
Hugo Parente Lima
Comment 4 2012-05-23 12:36:10 PDT
Created attachment 143621 [details] Attached HTML file rendered on WebKit
Alexandre Elias
Comment 5 2012-05-23 12:52:01 PDT
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.
Hugo Parente Lima
Comment 6 2012-05-23 12:52:26 PDT
webkit-dev thread about the scrollIntoView issue that affect this layout test: http://lists.webkit.org/pipermail/webkit-dev/2012-May/020805.html
Hugo Parente Lima
Comment 7 2012-05-23 12:56:39 PDT
(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.
Alexandre Elias
Comment 8 2012-05-23 13:02:07 PDT
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.
Csaba Osztrogonác
Comment 9 2012-10-09 01:51:08 PDT
It passes now, unskipped by r130738
Csaba Osztrogonác
Comment 10 2012-10-09 02:07:17 PDT
It isn't in the skipped list now.
Note You need to log in before you can comment on or make changes to this bug.