Bug 257992

<rdar://problem/111015539>

https://github.com/WebKit/WebKit/blob/6172ecd8b1485a5387d034f7e623a36b8f5a45fc/Source/WebCore/style/StyleAdjuster.cpp#L187 by adding ‘DisplayType::Block’? ^ Something here to also inherit text decoration effects?

Very likely same regression range as bug 250831

Created attachment 473189 [details] rendering in safari, firefox, chrome Apart of the last one, this is consitent. https://codepen.io/legion80/pen/YzRyqJO This is the one failing. <style>a.thick { text-decoration-thickness: 3px; }</style> <a href="#" class="thick"><span style="display:block">- link text inside span styled block</span></a>

Created attachment 479812 [details] testcase

Created attachment 479813 [details] rendering in safari, firefox, chrome (testcase) We can clearly see the issue.

This has an impact on the rendering of some tests on Bug 315487

Created attachment 479814 [details] testcase

Created attachment 479815 [details] rendering in safari, firefox, chrome (testcase)

While validating the patch for bug 315487 (dotted/dashed text-decoration phase reset across text-box boundaries), I came across what looks like another manifestation of this same propagation bug, on a different code path. Flagging it here so it's tracked together with the existing case rather than re-filed. ## Reproducer (testcase attached) Pure-inline structure, plain `<span>`: ```html <style> div { font: 92px Arial, sans-serif; text-decoration: dotted blue line-through; text-decoration-thickness: 30px; } </style> <div>foo<span>bar</span>baz</div> ``` The dotted line-through over `<span>bar</span>` is drawn at the `auto` resolution (~`font-size × 0.05` ≈ 4–6px) instead of the `<div>`'s `30px`. `foo` and `baz` render correctly at 30px. The dot diameter and period change at every `<span>` boundary, breaking the pattern visibly. Firefox 152 and Chrome 150 canary both render uniformly at 30px. The page also runs `getComputedStyle(span).textDecorationThickness` and prints as a result that returns `auto` in WebKit/Firefox/Chrome alike, which is **correct** per spec CSS Text Decoration 4 / 2.2 https://drafts.csswg.org/css-text-decor-4/#text-decoration-thickness-property `Inherited: no`. The bug is only that WebKit's painter then *uses* that descendant-side `auto` to draw the *ancestor's* decoration. `paintBackgroundDecorations` (underline / overline) and `paintForegroundDecorations` (line-through) take their thickness from different sources 1. `paintBackgroundDecorations`: `decoratingBox.style.get()` (set in `collectDecoratingBoxesForBackgroundPainting()` from the actual decorating box) (OK?) 2. `paintForegroundDecorations`: `decoratingBoxStyle(textBox)` → `parentInlineBox->style()` (wrong for inner non-decorating inline boxes?) Same markup, same line, same paint pass: underline thickness is uniform; line-through thickness isn't.

The spec says: > This property, which is a sub-property of the text-decoration shorthand, sets the stroke thickness of underlines, overlines, and line-throughs specified on the element with text-decoration-line, and affects all decorations originating from this element even if descendant boxes specify a different thickness. Things to look at, maybe more tests will be needed. * line-through y-position * textBoxPaintRect.width() is per-text-box see Bug 315487 phase-origin * vertical writing modes, Check also isLineInverted() * Ruby base * text-box-trim

Created attachment 479964 [details] Patch

^ This change fixes the original test case, Karl's test case was (partially) addressed by bug 316108.

Comment on attachment 479964 [details] Patch The asymmetry in the way we handle thickness vs style and color is a bit weird, and it makes lines like 993 auto textDecorationThickness = ceilToDevicePixel(decoratingBox.textDecorationStyles.linethrough.thickness, deviceScaleFactor); kinda confusing. Makes you think, why line through? What if we're painting only underlines? So maybe DecoratingBox should contain the color/style/thickness directly, and just have flags for the line types, to make it clear that there's one value for thickness (and style and color) for all of the lines. But that's a bit of a pre-existing problem, so r=fantasai. Might be worth adding a comment somewhere though, as to why we're pulling out only one thickness value and ignoring the rest.

Created attachment 479973 [details] [fast-cq]Patch

Committed 314502@main (40f72ef0f26d): <https://commits.webkit.org/314502@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 479973 [details].