Bug 274308

Summary:

(regression) -webkit-line-clamp showing one line less line with inline-block

Product:

WebKit

Reporter:

Tanel Terras <tanel.terras>

Component:

Layout and Rendering

Assignee:

zalan <zalan>

Status:

RESOLVED DUPLICATE

Severity:

Normal

CC:

bfulgham, fantasai.bugs, karlcow, simon.fraser, vitor.roriz, webkit-bug-importer, zalan

Priority:

Keywords:

BrowserCompat, InRadar

Version:

Safari 17

Hardware:

Mac (Apple Silicon)

OS:

macOS 14

Bug Depends on:

261030

Bug Blocks:

Attachments:

Description	Flags
rendering in safari, firefox, chrome	none
minimal tescase	none
rendering in safari, firefox, chrome (minimal test case)	none

Description Tanel Terras 2024-05-17 05:15:28 PDT

It seems that with fixes and changes in Safari 17, `-webkit-line-clamp` and `display: inline-block` causes weird bugs.
When clamped content includes elements with `display: inline-block`, -webkit-line-clamp value seems to subtracted by one (at least visually).

Examples: https://lit.dev/playground/#gist=4f7950f5ad46952aac643c501fa68f4e
Reproduction case includes two examples: Web Component that has slotted content (like in our Design System) and a regular lightDOM example with exact same visual behaviour.

When compared with Safari 16 the handling of `inline-block` element was much different - it seems to me visually that Safari 16 handled inline-block as inline element and in Safari 17 as block element.

Chrome and Firefox handle these cases as expected (by me) so figured it is a bug specific to Safari 17. Although Safari < 17 also has its quirks it is somewhat manageable in our use cases.

Comment 1 Tanel Terras 2024-05-17 05:28:00 PDT

Interesting observation from our Design System is also that when -webkit-line-clamp is toggled, Safari 17 clamps correctly after reassignment of -webkit-line-clamp.  

We are toggling on button click, then reassign -webkit-line-clamp with same initial value through JS.

Comment 2 Karl Dubost 2024-05-22 01:32:39 PDT

Created attachment 471469 [details]
rendering in safari, firefox, chrome

Thanks a lot Tanel for the report

1st paragraph shows 
  1 line in Safari 
  2 lines in Firefox/Chrome
2nd paragraph shows 
  2 lines in Safari 
  3 lines in Firefox/Chrome

Probably needs a simpler testcase. :)

Comment 3 Karl Dubost 2024-05-22 01:45:49 PDT

Created attachment 471471 [details]
minimal tescase

Load this testcase in all 3 browsers.

Comment 4 Karl Dubost 2024-05-22 01:46:45 PDT

Created attachment 471472 [details]
rendering in safari, firefox, chrome (minimal test case)

We can the difference in Safari when it includes an inline-block content.

Comment 5 Radar WebKit Bug Importer 2024-05-22 01:47:17 PDT

<rdar://problem/128527752>

Comment 6 Karl Dubost 2024-05-22 02:02:48 PDT

It's indeed a kind of regression.
Old build shows 2 lines but with the inline block being visible.

Comment 7 Karl Dubost 2024-05-22 02:29:26 PDT

This is a regression of https://github.com/WebKit/WebKit/commit/bf48ac60d4bb84f88ceb026495d8d9722be2ab5f

Bug 261030
rdar://problem/114878221

Comment 8 Karl Dubost 2024-05-22 02:31:47 PDT

<rdar://problem/128527752>

Comment 9 Karl Dubost 2024-05-22 02:36:34 PDT

So the fix from Alan, remove the inline block inside the line-clamp, but also in the same time reduced the line-clamp by one line. :)

Comment 10 Tanel Terras 2024-05-23 06:21:06 PDT

Thanks for looking into this!

Sorry for the overly complicated testcase. I was in process of ruling out that <slot> and its `display: contents` affect this somehow.

Comment 11 Tanel Terras 2024-09-04 05:46:45 PDT

Any updates on this regression?

Comment 12 zalan 2024-09-04 06:24:14 PDT

This works on trunk, processed at https://commits.webkit.org/282348@main (going to forward dupe it).

*** This bug has been marked as a duplicate of bug 277949 ***