Bug 115699
| Summary: | Round when converting percentage length to LayoutUnit | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> |
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | CC: | ahmad.saleem792, ap, bfulgham, rreno, simon.fraser, zalan |
| Priority: | P2 | Keywords: | BlinkMergeCandidate |
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Ryosuke Niwa
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
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
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
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
I think it's reasonable to close this. High risk with no obvious gain now that 10.5 years has passed!