RESOLVED WONTFIX 115699
Round when converting percentage length to LayoutUnit 
https://bugs.webkit.org/show_bug.cgi?id=115699
Summary Round when converting percentage length to LayoutUnit
Ryosuke Niwa
Reported 2013-05-06 20:00:34 PDT
We should consider merging https://chromium.googlesource.com/chromium/blink/+/ac373a32a830485b2011a1a2db98f0d990194ae9 Round when converting percentage length to LayoutUnit In minimumValueForLength we currently floor when converting from float to LayoutUnit for percentage lengths. This can lead to differences in width or height for elements using percentage lengths vs auto lengths.
Attachments
Add attachment proposed patch, testcase, etc.
Ahmad Saleem
Comment 1 2022-08-21 00:04:04 PDT
This required change in LengthFunctions.cpp: https://github.com/WebKit/WebKit/blob/ccec9222f68ce8174320c4579e1b329995324f85/Source/WebCore/platform/LengthFunctions.cpp#L71 I am not sure, I picked the correct and whether it was already refactored but just wanted to share and check if it is still needed or not. Thanks!
Ryan Reno
Comment 2 2022-08-22 14:37:37 PDT
Directly merging this as-is causes test regressions in imported/w3c/web-platform-tests/css/css-flexbox/flex-lines/multi-line-wrap-with-column-reverse.html imported/w3c/web-platform-tests/css/css-flexbox/flex-lines/multi-line-wrap-reverse-with-column-reverse.html As the window shrinks the 3-1 flex item which should be on the right edge of the viewport begins to strobe between wrapping into a fourth flex line and staying on the line it is expected to be on. The rounding behavior is interacting in a strange way with flex wrap computation. Since we're currently passing these tests and they're targets for interop 2022 (by virtue of being in interop 2021) it's risky to do this change when there aren't any other progressions beyond those progressions already landed.
Ahmad Saleem
Comment 3 2023-10-14 12:51:47 PDT
I took test case from Chrome Monorail, where this was highlighted as issue and changed it into JSFiddle: https://jsfiddle.net/jsy7nkq2/show Zooming in on bottom on intersection of these two containers, we don't have any mismatch in baseline alignment and we are matching both containers on baseline at least using Safari 17 on macOS Sonoma. @Ryan - Do we need to track it anymore or we can mark this as 'RESOLVED WONTFIX'?
Ryan Reno
Comment 4 2023-10-16 12:15:50 PDT
I think it's reasonable to close this. High risk with no obvious gain now that 10.5 years has passed!
Note You need to log in before you can comment on or make changes to this bug.