RESOLVED CONFIGURATION CHANGED 268529
REGRESSION: line-clamp doesn't work as expected with inline-block children
https://bugs.webkit.org/show_bug.cgi?id=268529
Summary REGRESSION: line-clamp doesn't work as expected with inline-block children
Fujii Hironori
Reported 2024-01-31 20:53:22 PST
Created attachment 469644 [details] test case REGRESSION: line-clamp doesn't work as expected with inline-block children
Attachments
test case (1.19 KB, text/html)
2024-01-31 20:53 PST, Fujii Hironori
no flags
[screenshot] STP 184 (93.06 KB, image/png)
2024-01-31 20:57 PST, Fujii Hironori
no flags
broken line clamp (not a regression) (73.63 KB, image/png)
2024-02-01 07:47 PST, alan baradlay
no flags
Patch to work around (1.08 KB, patch)
2024-02-14 22:42 PST, Fujii Hironori
no flags
Fujii Hironori
Comment 1 2024-01-31 20:57:26 PST
Created attachment 469645 [details] [screenshot] STP 184
Fujii Hironori
Comment 2 2024-01-31 21:04:30 PST Comment hidden (obsolete)
Fujii Hironori
Comment 3 2024-01-31 21:05:14 PST
My coworker did more bisecting. He says that 256989@main is the regression point.
Fujii Hironori
Comment 4 2024-01-31 21:34:48 PST
(In reply to Fujii Hironori from comment #2) > I did bisecting with my WinCairo collection. > > 256506@main good > 256728@main bad My bad. This is my real result. 256728@main good 257047@main bad
alan baradlay
Comment 5 2024-02-01 07:47:54 PST
Created attachment 469652 [details] broken line clamp (not a regression) Yeah, it looks like a regression caused by switching over to the new line-clamp implementation, but running line-clamp on inline-block was never really thought through (see screenshot attached, which is a slightly modified version of the test case where the inline text content is nested inside a block container <div>0 1 2 ...)
alan baradlay
Comment 6 2024-02-01 07:48:28 PST
(In reply to zalan from comment #5) > Created attachment 469652 [details] > broken line clamp (not a regression) > > Yeah, it looks like a regression caused by switching over to the new > line-clamp implementation, but running line-clamp on inline-block was never > really thought through (see screenshot attached, which is a slightly > modified version of the test case where the inline text content is nested > inside a block container <div>0 1 2 ...) <!DOCTYPE html> <html><head> <style> .paragraph { display: -webkit-box; overflow: hidden; -webkit-box-orient: vertical; -webkit-line-clamp: 3; line-clamp: 3; } span.a { background: green; display: inline-block; } </style> </head> <body> <div class="paragraph"><div> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100</div> <span class=a>xxx</span> <span class=a>xxx</span> </div> </body></html>
Fujii Hironori
Comment 7 2024-02-01 12:13:19 PST
Your test case (comment#6) works as expected with my STP. It shows only the first three lines. It doesn't yield comment#5 screenshot result. Your screenshot looks like overflow:hidden removed. Right?
alan baradlay
Comment 8 2024-02-01 15:10:13 PST
(In reply to Fujii Hironori from comment #7) > Your test case (comment#6) works as expected with my STP. It shows only the > first three lines. It doesn't yield comment#5 screenshot result. > Your screenshot looks like overflow:hidden removed. Right? the screenshot shows the rendering when the new line clamp implementation is disabled (essentially what we had before 256989@main)
Fujii Hironori
Comment 9 2024-02-01 16:26:38 PST
Your comment#5 screenshot looks like a correct result. It shows "..." at the bottom of the third line. It is the expected behavior of -webkit-line-clamp:3.
alan baradlay
Comment 10 2024-02-01 16:44:58 PST
(In reply to Fujii Hironori from comment #9) > Your comment#5 screenshot looks like a correct result. > It shows "..." at the bottom of the third line. > It is the expected behavior of -webkit-line-clamp:3. You are right, the ellipsis placement is correct, but that's pretty much the only thing that looks ok in there. It is surely not an overall desired rendering where the inline-block box _overlaps_ adjacent content and the block height is off by one line box.
Radar WebKit Bug Importer
Comment 11 2024-02-07 20:54:19 PST
Fujii Hironori
Comment 12 2024-02-14 22:42:43 PST
Created attachment 469872 [details] Patch to work around
Fujii Hironori
Comment 13 2024-08-27 00:51:14 PDT
works for me.
alan baradlay
Comment 14 2024-08-27 05:17:21 PDT
This has progressed with Antti's recent work where we finally run inline-block layout as part of IFC and not before.
Antti Koivisto
Comment 15 2024-08-27 08:54:33 PDT
nice!
Note You need to log in before you can comment on or make changes to this bug.