Bug 279008

Summary: text-emphasis only uses the first character in the grapheme cluster
Product: WebKit Reporter: yisibl <50167214>
Component: TextAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: ap, fantasai.bugs, karlcow, koivisto, ntim, vitor.roriz, webkit-bug-importer, zalan
Priority: P2 Keywords: BrowserCompat, InRadar
Version: Safari Technology Preview   
Hardware: Mac (Apple Silicon)   
OS: Unspecified   
Attachments:
Description Flags
text-emphasis-emoji
none
test case none

yisibl
Reported 2024-09-02 00:00:03 PDT
Created attachment 472401 [details] text-emphasis-emoji Open the following code in Safari and you'll see that the text-emphasis is only rendered to `U+2764` data:text/html;charset=UTF-8,<!doctype html> <style> .foo { font-size: 52px; border: solid 1px blue; text-emphasis-style: "❤️"; display: inline; } </style> <div class="foo">test emoji❤️</div> ❤️ This emoji actually contains two characters: `U+2764` `U+FE0F`
Attachments
text-emphasis-emoji (741.18 KB, image/png)
2024-09-02 00:00 PDT, yisibl 		no flags
Details
test case (198 bytes, text/html)
2024-09-02 12:38 PDT, Alexey Proskuryakov 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2024-09-02 02:08:03 PDT
<rdar://problem/135133566>
Alexey Proskuryakov
Comment 2 2024-09-02 12:37:55 PDT
This is not just emoji with variation selectors. Same issue with e.g. decomposed é, or regional indicators like 🇷🇺.
Alexey Proskuryakov
Comment 3 2024-09-02 12:38:29 PDT
Created attachment 472406 [details] test case Same test as attachment.
alan
Comment 4 2024-09-02 13:39:10 PDT
Looks like drawEmphasisMarks is broken. using drawBidiText instead makes the bug go away (note that this is not a fix proposal) diff --git a/Source/WebCore/rendering/TextPainter.cpp b/Source/WebCore/rendering/TextPainter.cpp index 8a84ad92b70b..4be4f964b5b9 100644 --- a/Source/WebCore/rendering/TextPainter.cpp +++ b/Source/WebCore/rendering/TextPainter.cpp @@ -117,7 +117,7 @@ void TextPainter::paintTextOrEmphasisMarks(const FontCascade& font, const TextRu } if (!emphasisMark.isEmpty()) - m_context.drawEmphasisMarks(font, textRun, emphasisMark, textOrigin + FloatSize(0, emphasisMarkOffset), startOffset, endOffset); + m_context.drawBidiText(font, TextRun { emphasisMark.string() }, textOrigin + FloatSize(0, emphasisMarkOffset)); else if (startOffset || endOffset < textRun.length() || !m_glyphDisplayList) m_context.drawText(font, textRun, textOrigin, startOffset, endOffset); else {
alan
Comment 5 2024-09-04 09:21:04 PDT
Maybe we use the wrong font? Seeing this FIXME comment in getEmphasisMarkGlyphData does not give me too much confidence. // FIXME: This function may not work if the emphasis mark uses a complex script, but none of the // standard emphasis marks do so. std::optional<GlyphData> FontCascade::getEmphasisMarkGlyphData(const AtomString& mark) const
yisibl
Comment 6 2025-10-28 05:15:29 PDT
Friendly ping
Karl Dubost
Comment 7 2025-10-28 06:18:22 PDT
The FIXME was added in https://searchfox.org/wubkat/diff/4bfb080f7915539db5c634e19556417d75eee993/WebCore/platform/graphics/FontFastPath.cpp#200-202 in 2010. https://bugs.webkit.org/show_bug.cgi?id=48539 (WebCore::Font::getEmphasisMarkGlyphData): Added. Returns glyph data for the first character of the emphasis mark. This function may not work if the emphasis mark uses a complex script, but none of the standard emphasis marks do so.
alan
Comment 8 2025-10-28 14:19:43 PDT
I did some debugging, and it looks like FontCascade::getEmphasisMarkGlyphData should be using a grapheme cluster iterator instead of the surrogate pair iterator we currently use. Elika/Vitor may have some insights here.
Note You need to log in before you can comment on or make changes to this bug.