Title: [280893] releases/WebKitGTK/webkit-2.32/Source/WebCore
- Revision
- 280893
- Author
- [email protected]
- Date
- 2021-08-11 03:14:26 -0700 (Wed, 11 Aug 2021)
Log Message
Merge r274398 - RenderLineBreak should stay inline level box even when display property says otherwise.
https://bugs.webkit.org/show_bug.cgi?id=223151
<rdar://74339837>
Reviewed by Antti Koivisto.
In this patch we make sure that the RenderLineBreak object always stays inline.
While the display property applies to all elements (https://drafts.csswg.org/css-display/#the-display-properties), the line
break element (<br>) seems to be an exception and all browsers handle <br style="display: block"> still as an inline level element.
Renderers can (and do see RenderSVGInline::updateFromStyle) diverge from this computed display value and say they always want to
be inline level boxes. This is ensured by RenderObject::setInline/isInline function pair.
Initially there were 2 setInline() calls:
One in RenderObject::setStyle(). It dealt with "block to inline" transition and
one call in RenderBox::setStyle().
In these functions we simply set the renderer's "inInline" bit to the computed style value (setInline(style.isDisplayInlineType)).
However derived renderer classes were able to override it by implementing the ::setStyle function and
explicitly set the "isInline" bit to true/false.
Over the years the second (RenderBox::setStyle) call transitioned to RenderBoxModelObject::updateFromStyle()
and the first (RenderObject::setStyle) call got moved to normalizeTreeAfterStyleChange() and their order got flipped.
Derived renderer classes can still explicitly set the "isInline" bit by implementing the ::updateFromStyle() function
(this is similar to what we had with ::setStyle).
However since the order is flipped, the "setInline()" call in normalizeTreeAfterStyleChange() now runs after
updateFromStyle() and it may re-reset the "isInline" bit back to the computed value (hence the FIXME).
The "setInline" call in normalizeTreeAfterStyleChange() is not needed anymore since the "isInline" bit is already updated by
the time we get here (as opposed to when it was initially introduced in RenderObject::setStyle, see above).
* rendering/RenderLineBreak.cpp:
(WebCore::RenderLineBreak::updateFromStyle):
* rendering/updating/RenderTreeBuilder.cpp:
(WebCore::RenderTreeBuilder::normalizeTreeAfterStyleChange):
Modified Paths
Diff
Modified: releases/WebKitGTK/webkit-2.32/Source/WebCore/ChangeLog (280892 => 280893)
--- releases/WebKitGTK/webkit-2.32/Source/WebCore/ChangeLog 2021-08-11 10:13:25 UTC (rev 280892)
+++ releases/WebKitGTK/webkit-2.32/Source/WebCore/ChangeLog 2021-08-11 10:14:26 UTC (rev 280893)
@@ -1,3 +1,42 @@
+2021-03-14 Zalan Bujtas <[email protected]>
+
+ RenderLineBreak should stay inline level box even when display property says otherwise.
+ https://bugs.webkit.org/show_bug.cgi?id=223151
+ <rdar://74339837>
+
+ Reviewed by Antti Koivisto.
+
+ In this patch we make sure that the RenderLineBreak object always stays inline.
+
+ While the display property applies to all elements (https://drafts.csswg.org/css-display/#the-display-properties), the line
+ break element (<br>) seems to be an exception and all browsers handle <br style="display: block"> still as an inline level element.
+
+ Renderers can (and do see RenderSVGInline::updateFromStyle) diverge from this computed display value and say they always want to
+ be inline level boxes. This is ensured by RenderObject::setInline/isInline function pair.
+
+ Initially there were 2 setInline() calls:
+ One in RenderObject::setStyle(). It dealt with "block to inline" transition and
+ one call in RenderBox::setStyle().
+ In these functions we simply set the renderer's "inInline" bit to the computed style value (setInline(style.isDisplayInlineType)).
+ However derived renderer classes were able to override it by implementing the ::setStyle function and
+ explicitly set the "isInline" bit to true/false.
+
+ Over the years the second (RenderBox::setStyle) call transitioned to RenderBoxModelObject::updateFromStyle()
+ and the first (RenderObject::setStyle) call got moved to normalizeTreeAfterStyleChange() and their order got flipped.
+
+ Derived renderer classes can still explicitly set the "isInline" bit by implementing the ::updateFromStyle() function
+ (this is similar to what we had with ::setStyle).
+ However since the order is flipped, the "setInline()" call in normalizeTreeAfterStyleChange() now runs after
+ updateFromStyle() and it may re-reset the "isInline" bit back to the computed value (hence the FIXME).
+
+ The "setInline" call in normalizeTreeAfterStyleChange() is not needed anymore since the "isInline" bit is already updated by
+ the time we get here (as opposed to when it was initially introduced in RenderObject::setStyle, see above).
+
+ * rendering/RenderLineBreak.cpp:
+ (WebCore::RenderLineBreak::updateFromStyle):
+ * rendering/updating/RenderTreeBuilder.cpp:
+ (WebCore::RenderTreeBuilder::normalizeTreeAfterStyleChange):
+
2021-03-13 Zalan Bujtas <[email protected]>
Mark the line dirty when list marker goes from inline to block
Modified: releases/WebKitGTK/webkit-2.32/Source/WebCore/rendering/RenderLineBreak.cpp (280892 => 280893)
--- releases/WebKitGTK/webkit-2.32/Source/WebCore/rendering/RenderLineBreak.cpp 2021-08-11 10:13:25 UTC (rev 280892)
+++ releases/WebKitGTK/webkit-2.32/Source/WebCore/rendering/RenderLineBreak.cpp 2021-08-11 10:14:26 UTC (rev 280893)
@@ -174,6 +174,7 @@
void RenderLineBreak::updateFromStyle()
{
m_cachedLineHeight = invalidLineHeight;
+ RELEASE_ASSERT_WITH_SECURITY_IMPLICATION(isInline());
}
#if PLATFORM(IOS_FAMILY)
Modified: releases/WebKitGTK/webkit-2.32/Source/WebCore/rendering/updating/RenderTreeBuilder.cpp (280892 => 280893)
--- releases/WebKitGTK/webkit-2.32/Source/WebCore/rendering/updating/RenderTreeBuilder.cpp 2021-08-11 10:13:25 UTC (rev 280892)
+++ releases/WebKitGTK/webkit-2.32/Source/WebCore/rendering/updating/RenderTreeBuilder.cpp 2021-08-11 10:14:26 UTC (rev 280893)
@@ -577,9 +577,6 @@
// We have gone from not affecting the inline status of the parent flow to suddenly
// having an impact. See if there is a mismatch between the parent flow's
// childrenInline() state and our state.
- // FIXME(186894): startsAffectingParent has clearly nothing to do with resetting the inline state.
- if (!is<RenderSVGInline>(renderer))
- renderer.setInline(renderer.style().isDisplayInlineType());
if (renderer.isInline() != renderer.parent()->childrenInline())
childFlowStateChangesAndAffectsParentBlock(renderer);
return;
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
