Title: [287724] trunk
- Revision
- 287724
- Author
- [email protected]
- Date
- 2022-01-06 15:50:19 -0800 (Thu, 06 Jan 2022)
Log Message
REGRESSION(r281389): Text wraps unnecessarily within intrinsically-sized elements when using certain fonts and the inner HTML of the element contains a new line that is not preceded by a space
https://bugs.webkit.org/show_bug.cgi?id=232939
<rdar://problem/85254819>
Reviewed by Alan Bujtas.
Source/WebCore:
We need newline characters to have the same width as space characters for 2 reasons:
1. Our code implicitly depends on it. We have places where we measure a newline character in one place,
and then later realize that we shouldn't have included its with so we subtract out the width of
the space character. (For more information, read the comments of this bugzilla bug.) This assumes
that the width of the newline character is equal to the width of the space character.
2. We need it for correctness. Even if WebKit was entirely consistent about measuring the width of
newline characters, we don't want to have the width of an element depend on the width of the
newline character in the font. Every other browser forces newline characters to have the same
width as space characters. And, even if we weren't concerned about compatibility (we are),
we'd be producing bogus results because font designers aren't incentivized to put any meaningful
values in their fonts for the width of a newline character, since no software actually uses it.
Luckily, we already have our "charactersTreatedAsSpace" infrastructure, so we can just tweak it to have
it set characters which are treated as space, but aren't the tab character, to have the same width as
the space character.
Test: fast/text/newline-width.html
* platform/graphics/WidthIterator.cpp:
(WebCore::WidthIterator::advanceInternal):
LayoutTests:
The div:before { position: absolute; } is necessary to trigger this bug; I assume it's necessary to
opt-out of IFC.
* fast/text/newline-width-expected.html: Added.
* fast/text/newline-width.html: Added.
Modified Paths
Added Paths
Diff
Modified: trunk/LayoutTests/ChangeLog (287723 => 287724)
--- trunk/LayoutTests/ChangeLog 2022-01-06 23:42:36 UTC (rev 287723)
+++ trunk/LayoutTests/ChangeLog 2022-01-06 23:50:19 UTC (rev 287724)
@@ -1,3 +1,17 @@
+2022-01-06 Myles C. Maxfield <[email protected]>
+
+ REGRESSION(r281389): Text wraps unnecessarily within intrinsically-sized elements when using certain fonts and the inner HTML of the element contains a new line that is not preceded by a space
+ https://bugs.webkit.org/show_bug.cgi?id=232939
+ <rdar://problem/85254819>
+
+ Reviewed by Alan Bujtas.
+
+ The div:before { position: absolute; } is necessary to trigger this bug; I assume it's necessary to
+ opt-out of IFC.
+
+ * fast/text/newline-width-expected.html: Added.
+ * fast/text/newline-width.html: Added.
+
2022-01-06 Tim Nguyen <[email protected]>
Unprefix -webkit-print-color-adjust CSS property
Added: trunk/LayoutTests/fast/text/newline-width-expected.html (0 => 287724)
--- trunk/LayoutTests/fast/text/newline-width-expected.html (rev 0)
+++ trunk/LayoutTests/fast/text/newline-width-expected.html 2022-01-06 23:50:19 UTC (rev 287724)
@@ -0,0 +1,17 @@
+<!DOCTYPE html> <!-- webkit-test-runner [ LayoutFormattingContextIntegrationEnabled=false ] -->
+<html>
+<head>
+<style>
+div {
+ font: expanded 48px 'Apple Chancery';
+ white-space: nowrap;
+ display: inline-block;
+ background: green;
+}
+</style>
+</head>
+<body>
+This test makes sure that newline characters have the same widths as space characters. We're using Apple Chancery here because the font its newline character is much wider than its space character.
+<p><div> a b c d e</div></p>
+</body>
+</html>
Added: trunk/LayoutTests/fast/text/newline-width.html (0 => 287724)
--- trunk/LayoutTests/fast/text/newline-width.html (rev 0)
+++ trunk/LayoutTests/fast/text/newline-width.html 2022-01-06 23:50:19 UTC (rev 287724)
@@ -0,0 +1,23 @@
+<!DOCTYPE html> <!-- webkit-test-runner [ LayoutFormattingContextIntegrationEnabled=false ] -->
+<html>
+<head>
+<style>
+div {
+ font: expanded 48px 'Apple Chancery';
+ white-space: pre-wrap;
+ white-space: nowrap;
+ display: inline-block;
+ background: green;
+}
+</style>
+</head>
+<body>
+This test makes sure that newline characters have the same widths as space characters. We're using Apple Chancery here because the font its newline character is much wider than its space character.
+<p><div>
+a
+b
+c
+d
+e</div></p>
+</body>
+</html>
Modified: trunk/Source/WebCore/ChangeLog (287723 => 287724)
--- trunk/Source/WebCore/ChangeLog 2022-01-06 23:42:36 UTC (rev 287723)
+++ trunk/Source/WebCore/ChangeLog 2022-01-06 23:50:19 UTC (rev 287724)
@@ -1,3 +1,32 @@
+2022-01-06 Myles C. Maxfield <[email protected]>
+
+ REGRESSION(r281389): Text wraps unnecessarily within intrinsically-sized elements when using certain fonts and the inner HTML of the element contains a new line that is not preceded by a space
+ https://bugs.webkit.org/show_bug.cgi?id=232939
+ <rdar://problem/85254819>
+
+ Reviewed by Alan Bujtas.
+
+ We need newline characters to have the same width as space characters for 2 reasons:
+ 1. Our code implicitly depends on it. We have places where we measure a newline character in one place,
+ and then later realize that we shouldn't have included its with so we subtract out the width of
+ the space character. (For more information, read the comments of this bugzilla bug.) This assumes
+ that the width of the newline character is equal to the width of the space character.
+ 2. We need it for correctness. Even if WebKit was entirely consistent about measuring the width of
+ newline characters, we don't want to have the width of an element depend on the width of the
+ newline character in the font. Every other browser forces newline characters to have the same
+ width as space characters. And, even if we weren't concerned about compatibility (we are),
+ we'd be producing bogus results because font designers aren't incentivized to put any meaningful
+ values in their fonts for the width of a newline character, since no software actually uses it.
+
+ Luckily, we already have our "charactersTreatedAsSpace" infrastructure, so we can just tweak it to have
+ it set characters which are treated as space, but aren't the tab character, to have the same width as
+ the space character.
+
+ Test: fast/text/newline-width.html
+
+ * platform/graphics/WidthIterator.cpp:
+ (WebCore::WidthIterator::advanceInternal):
+
2022-01-06 Tim Horton <[email protected]>
Separate "linked-on-or-{before, after}-everything" override from the SDK version
Modified: trunk/Source/WebCore/platform/graphics/WidthIterator.cpp (287723 => 287724)
--- trunk/Source/WebCore/platform/graphics/WidthIterator.cpp 2022-01-06 23:42:36 UTC (rev 287723)
+++ trunk/Source/WebCore/platform/graphics/WidthIterator.cpp 2022-01-06 23:50:19 UTC (rev 287724)
@@ -313,13 +313,8 @@
else
widthOfCurrentFontRange += width;
- if (FontCascade::treatAsSpace(character)) {
- charactersTreatedAsSpace.constructAndAppend(
- currentCharacterIndex,
- character == ' ',
- previousWidth,
- width);
- }
+ if (FontCascade::treatAsSpace(character))
+ charactersTreatedAsSpace.constructAndAppend(currentCharacterIndex, character == space, previousWidth, character == tabCharacter ? width : font.spaceWidth());
if (m_accountForGlyphBounds) {
bounds = font.boundsForGlyph(glyph);
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
