The following reftests are failing after (most likely) changes in r159166: fast/block/float/float-with-fractional-height-vertical-lr.html fast/block/float/float-with-fractional-height.html http://trac.webkit.org/changeset/159166 http://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=fast%2Fblock%2Ffloat%2Ffloat-with-fractional-height-vertical-lr.html%20fast%2Fblock%2Ffloat%2Ffloat-with-fractional-height.html The GTK port enables subpixel layout. EFL does as well though, and there's no regression there AFAIK.
Both tests are failing on EFL too - EFL bot does not show results when 'Show all runs' is enabled http://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Fblock%2Ffloat%2Ffloat-with-fractional-height-vertical-lr.html%20fast%2Fblock%2Ffloat%2Ffloat-with-fractional-height.html Failures are the same as on GTK: http://build.webkit.org/results/EFL%20Linux%2064-bit%20Release%20WK2/r159559%20%2811520%29/fast/block/float/float-with-fractional-height-vertical-lr-diffs.html http://build.webkit.org/results/EFL%20Linux%2064-bit%20Release%20WK2/r159559%20%2811520%29/fast/block/float/float-with-fractional-height-diffs.html
That's unfortunate. I'll get a GTK or EFL build working and look into it.
As far as I can tell, this is happening because the test is running afoul of IEEE floating point being imprecise. It is expecting 1.2 + 1.2 + 1.2 to be >= 3.6, but that isn't happening in practice, so the last line of the test is seen as overlapping the float. I'll see if I can come up with some numbers that always add up correctly to change the test to fix the issue.
(In reply to comment #3) > As far as I can tell, this is happening because the test is running afoul of IEEE floating point being imprecise. It is expecting 1.2 + 1.2 + 1.2 to be >= 3.6, but that isn't happening in practice, so the last line of the test is seen as overlapping the float. I'll see if I can come up with some numbers that always add up correctly to change the test to fix the issue. I take that back, that's not what's happening. It looks like converting to layout units broke the fix for bug 112744, so I'm looking for another solution, if I don't find one, I guess I'll just have to put the placed floats tree back as ints, or truncate the layout units coming in.
Created attachment 219424 [details] Patch
(In reply to comment #5) > Created an attachment (id=219424) [details] > Patch This patch fixes the issue by flooring the floating object interval endpoints to revert to the old behavior. I have filed bug 125831 to track coming up with a better fix.
Comment on attachment 219424 [details] Patch Not great to have a hack for that :/
Comment on attachment 219424 [details] Patch Clearing flags on attachment: 219424 Committed r160715: <http://trac.webkit.org/changeset/160715>
All reviewed patches have been landed. Closing bug.