Bug 124506 – REGRESSION(r159166?): fast/block/float/float-with-fractional-height-vertical-lr.html, fast/block/float/float-with-fractional-height.html are failing

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Zan Dobersek]

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.

[Michal Pakula vel Rutka]

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

[Bem Jones-Bey]

That's unfortunate. I'll get a GTK or EFL build working and look into it.

[Bem Jones-Bey]

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.

[Bem Jones-Bey]

(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.

[Bem Jones-Bey]

Created attachment 219424 [details]
Patch

[Bem Jones-Bey]

(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.

[Dirk Schulze]

Comment on attachment 219424 [details]
Patch

Not great to have a hack for that :/

[WebKit Commit Bot]

Comment on attachment 219424 [details]
Patch

Clearing flags on attachment: 219424

Committed r160715: <http://trac.webkit.org/changeset/160715>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.