Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 892029d23764c2c8f0cda40bd46c7aa70d8f3c76
https://github.com/WebKit/WebKit/commit/892029d23764c2c8f0cda40bd46c7aa70d8f3c76
Author: Megan Gardner <[email protected]>
Date: 2026-07-28 (Tue, 28 Jul 2026)
Changed paths:
M LayoutTests/TestExpectations
M LayoutTests/fast/repaint/text-decoration-overflow-repaint-expected.txt
M
LayoutTests/fast/repaint/vertical-rl-repaint-when-decoration-changes-expected.txt
M
Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayContentBuilder.cpp
M Source/WebCore/style/InlineTextBoxStyle.cpp
Log Message:
-----------
[Custom Highlight] text-underline-offset is mispositioned in vertical writing
mode.
https://bugs.webkit.org/show_bug.cgi?id=319963
rdar://182889143
Reviewed by Alan Baradlay.
In a vertical writing mode with text-underline-position: auto, the underline
should be under-aligned (to the text's under edge),
with text-underline-offset shifting it from there. isAlignedForUnder()
additionally required text-underline-offset to be auto,
so specifying an explicit offset dropped the text out of the under-alignment
path into the horizontal ascent + offset computation,
positioning the underline incorrectly. This was exposed by custom highlights: a
::highlight carries its offset as an override on an
originating box whose own offset is auto, so the highlight under-aligned
correctly while an equivalently-styled plain element
(with a non-auto offset) did not — the two diverged in vertical-lr. Dropping
the offset condition lets any vertical
text-underline-position: auto text under-align, applying the offset within that
branch, so highlights and directly-styled elements agree.
Correcting the underline position surfaced a second, pre-existing issue in the
ink-overflow (repaint) path:
collectInkOverflowForTextDecorations passed the run's physical height as the
logical run height, which is only correct in horizontal
writing modes. Once the underline under-aligns in vertical text, this
over-inflated the computed ink overflow and the tracked repaint
rectangle. It now uses the run's block-axis extent (physical width in vertical
writing modes), matching the paint path, so the repaint
rects stay tight. The two fast/repaint baselines are updated to reflect the
corrected underline position.
This addresses only the offset-gated under-alignment and its repaint
side-effect; other vertical decoration-positioning issues
(e.g. the non-root path FIXME in TextBoxPainter.cpp, and
custom-highlight-painting-vertical-writing-mode-001) are unrelated and remain.
imported/w3c/web-platform-tests/css/css-highlight-api/painting/custom-highlight-logical-metrics-002.html
imported/w3c/web-platform-tests/css/css-highlight-api/painting/custom-highlight-dynamic-logical-metrics-001.html
* LayoutTests/TestExpectations:
* LayoutTests/fast/repaint/text-decoration-overflow-repaint-expected.txt:
*
LayoutTests/fast/repaint/vertical-rl-repaint-when-decoration-changes-expected.txt:
*
Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayContentBuilder.cpp:
(WebCore::Layout::InlineDisplayContentBuilder::collectInkOverflowForTextDecorations):
* Source/WebCore/style/InlineTextBoxStyle.cpp:
(WebCore::isAlignedForUnder):
Canonical link: https://commits.webkit.org/318107@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
