Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 7a12760719f1be2057e8d1d6732f9e99a14bd89e
https://github.com/WebKit/WebKit/commit/7a12760719f1be2057e8d1d6732f9e99a14bd89e
Author: Megan Gardner <[email protected]>
Date: 2026-08-24 (Mon, 24 Aug 2026)
Changed paths:
M Source/WebCore/editing/Editor.cpp
M Tools/Scripts/webkitpy/api_tests/allowlist.txt
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/mac/FontManagerTests.mm
Log Message:
-----------
[Mail]: Formatting does not apply properly to line breaks, causing the
selectors to appear blank.
https://bugs.webkit.org/show_bug.cgi?id=322227
rdar://177949036
Reviewed by Ryosuke Niwa and Abrar Rahman Protyasha.
In Mail, type a line, hit Return, type some more, then select all and change
the font or size:
the font and size selectors go blank.
Editor::fontForSelection decides hasMultipleFonts by comparing the primary font
of every node in
the selection, and that includes any <br>. A <br> that isn't inside a styled
wrapper inherits its
font from an ancestor, so this comes back as "multiple" even though every bit
of text is Helvetica:
<font face=Helvetica>First</font><br><font face=Helvetica>Second</font>
On macOS that lands in -[NSFontManager setSelectedFont:isMultiple:], which
blanks out the panel's fields.
So stop letting a line break's font decide this; it contributes no text and
shouldn't outvote the text
that's actually selected. It's kept as a fallback rather than skipped outright,
because a selection
containing only a line break still has to report something — otherwise
NSFontAttributeName drops out of
the dictionary and clients get empty attributes instead of a merely wrong font.
This overturns the expectation added in 308562@main, which fixed the
neighboring unstyled-wrapper case and
recorded the line-break case as reporting multiple fonts. That commit's stated
rule was to count only
"elements with immediate text node children", which a <br> isn't, so the
carve-out reads as preserving
old behavior rather than asking for it, and neither the bug nor the PR says
otherwise. It is a real
trade: a bare <br> on a blank line does affect that line's height, so a
selection containing one is no
longer reported as mixed. For a formatting UI, showing the selected text's font
is the more useful answer.
Test: Tools/TestWebKitAPI/Tests/WebKit/WKWebView/mac/FontManagerTests.mm
* Source/WebCore/editing/Editor.cpp:
(WebCore::Editor::fontForSelection):
* Tools/Scripts/webkitpy/api_tests/allowlist.txt:
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/mac/FontManagerTests.mm:
(TestWebKitAPI::TEST(FontManagerTests,
SelectionSpanningBRDoesNotReportMultipleFonts)):
(TestWebKitAPI::TEST(FontManagerTests,
SelectionContainingOnlyBRStillReportsAFont)):
(TestWebKitAPI::TEST(FontManagerTests,
SelectionSpanningBRDoesReportMultipleFonts)): Deleted.
Canonical link: https://commits.webkit.org/319747@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
