Bug 230755

Summary: [css-flexbox] Improve & simplify the flex-basis computation
Product: WebKit Reporter: Sergio Villar Senin <svillar>
Component: New BugsAssignee: Sergio Villar Senin <svillar>
Status: RESOLVED FIXED    
Severity: Normal CC: cdumez, changseok, esprehn+autocc, ews-watchlist, glenn, jbedard, koivisto, kondapallykalyan, pdr, rbuis, rego, rniwa, sihui_liu, simon.fraser, svillar, webkit-bug-importer, youennf, ysuzuki, zalan
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=240068
Bug Depends on: 232481    
Bug Blocks:    
Attachments:
Description Flags
Patch
none
Patch for landing
none
Patch zalan: review+, ews-feeder: commit-queue-

Sergio Villar Senin
Reported 2021-09-24 09:36:50 PDT
[css-flexbox] Improve & simplify the flex-basis computation
Attachments
Patch (17.06 KB, patch)
2021-09-24 10:09 PDT, Sergio Villar Senin
no flags
Patch for landing (17.23 KB, patch)
2021-10-15 01:39 PDT, Sergio Villar Senin
no flags
Patch (25.61 KB, patch)
2021-11-10 02:35 PST, Sergio Villar Senin
zalan: review+
ews-feeder: commit-queue-
Sergio Villar Senin
Comment 1 2021-09-24 10:09:42 PDT
Sergio Villar Senin
Comment 2 2021-10-01 04:39:56 PDT
Gentle ping for reviewers
Radar WebKit Bug Importer
Comment 3 2021-10-01 09:39:59 PDT
Rob Buis
Comment 4 2021-10-05 00:20:31 PDT
Comment on attachment 439157 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=439157&action=review > Source/WebCore/rendering/RenderFlexibleBox.cpp:1016 > + m_child.mutableStyle().setLogicalWidth(Length(m_originalMainAxisLength)); Temp Length not needed. > Source/WebCore/rendering/RenderFlexibleBox.cpp:1018 > + m_child.mutableStyle().setLogicalHeight(Length(m_originalMainAxisLength)); Ditto.
Sergio Villar Senin
Comment 5 2021-10-06 09:39:37 PDT
Any other comment regarding this patch?
Sergio Villar Senin
Comment 6 2021-10-08 07:48:00 PDT
(In reply to Rob Buis from comment #4) > Comment on attachment 439157 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=439157&action=review > > > Source/WebCore/rendering/RenderFlexibleBox.cpp:1016 > > + m_child.mutableStyle().setLogicalWidth(Length(m_originalMainAxisLength)); > > Temp Length not needed. You actually need that or a WTFMove
Rob Buis
Comment 7 2021-10-08 08:04:35 PDT
Comment on attachment 439157 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=439157&action=review >>> Source/WebCore/rendering/RenderFlexibleBox.cpp:1016 >>> + m_child.mutableStyle().setLogicalWidth(Length(m_originalMainAxisLength)); >> >> Temp Length not needed. > > You actually need that or a WTFMove Ah I see! WTFMove would be more efficient here, right?
Manuel Rego Casasnovas
Comment 8 2021-10-13 04:34:56 PDT
Comment on attachment 439157 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=439157&action=review Nice patch, I have some comments and questions inline. > Source/WebCore/rendering/RenderFlexibleBox.cpp:999 > +class ScopedFlexBasisAsMainSize { Wow, this is quite a hack I guess we don't have a better alternative though. :-( I'm not really sure about the class name, would be better ScopedFlexBasisAsChildSize? Or something else, not sure... > Source/WebCore/rendering/RenderFlexibleBox.cpp:1007 > + m_child.mutableStyle().setLogicalWidth(Length(flexBasis)); Does this works fine if the element has something like "max-width: 100px;" or "min-width: 1000px;". Not sure if preferred widths are recomputed or not after this call. > Source/WebCore/rendering/RenderFlexibleBox.cpp:1023 > + Length m_originalMainAxisLength; Why not just "m_originalSize" or "m_originalChildSize"? > Source/WebCore/rendering/RenderFlexibleBox.cpp:1040 > + // 9.3.2 E. Otherwise, size the item into the available space using its used flex basis in place of its main size. I miss C) and D) before getting to E). Maybe we could add a comment. > Source/WebCore/rendering/RenderFlexibleBox.cpp:1047 > + if (childHasIntrinsicMainAxisSize(child)) > + child.setNeedsLayout(MarkOnlyThis); Why we need this? > Source/WebCore/rendering/RenderFlexibleBox.cpp:1048 > + child.layoutIfNeeded(); Ditto about this like, do we need this if we haven't gone through the previous if statement?
Sergio Villar Senin
Comment 9 2021-10-13 05:11:07 PDT
Comment on attachment 439157 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=439157&action=review >> Source/WebCore/rendering/RenderFlexibleBox.cpp:1007 >> + m_child.mutableStyle().setLogicalWidth(Length(flexBasis)); > > Does this works fine if the element has something like "max-width: 100px;" or "min-width: 1000px;". > Not sure if preferred widths are recomputed or not after this call. This is a nice question. When computing the flex-base size the min|max constrains should not apply. We are not doing that at the moment, however that is properly addressed in https://bugs.webkit.org/show_bug.cgi?id=225590. That bug landed and caused some regression, I have a local patch that implements https://bugs.webkit.org/show_bug.cgi?id=225590 on top of this patch and that does not regress anything. >> Source/WebCore/rendering/RenderFlexibleBox.cpp:1023 >> + Length m_originalMainAxisLength; > > Why not just "m_originalSize" or "m_originalChildSize"? OK, I don't have a strong opinion here. >> Source/WebCore/rendering/RenderFlexibleBox.cpp:1040 >> + // 9.3.2 E. Otherwise, size the item into the available space using its used flex basis in place of its main size. > > I miss C) and D) before getting to E). Maybe we could add a comment. They've not been implemented yet. >> Source/WebCore/rendering/RenderFlexibleBox.cpp:1047 >> + child.setNeedsLayout(MarkOnlyThis); > > Why we need this? We were already doing this in the code that was removed from constructFlexItem(). At this point we know that we need to return the logical height of the item so we must ensure that we have an updated value for the height before. The only way to do that is laying out the item >> Source/WebCore/rendering/RenderFlexibleBox.cpp:1048 >> + child.layoutIfNeeded(); > > Ditto about this like, do we need this if we haven't gone through the previous if statement? Yep, because you don't have the height until you layout the item.
Manuel Rego Casasnovas
Comment 10 2021-10-14 04:48:41 PDT
Comment on attachment 439157 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=439157&action=review r=me >> Source/WebCore/rendering/RenderFlexibleBox.cpp:999 >> +class ScopedFlexBasisAsMainSize { > > Wow, this is quite a hack I guess we don't have a better alternative though. :-( > > I'm not really sure about the class name, would be better ScopedFlexBasisAsChildSize? Or something else, not sure... Could we add some brief documentation about this class? Is it not very big, but it's a kind of very special case, so it's worth explaining it for the future. >>> Source/WebCore/rendering/RenderFlexibleBox.cpp:1040 >>> + // 9.3.2 E. Otherwise, size the item into the available space using its used flex basis in place of its main size. >> >> I miss C) and D) before getting to E). Maybe we could add a comment. > > They've not been implemented yet. I'd add a comment for clarity, otherwise it's kind of confusing.
zalan
Comment 11 2021-10-14 19:49:23 PDT
👍
Sergio Villar Senin
Comment 12 2021-10-15 01:39:59 PDT
Created attachment 441350 [details] Patch for landing
Sergio Villar Senin
Comment 13 2021-10-18 03:08:03 PDT
Yusuke Suzuki
Comment 14 2021-10-29 13:18:59 PDT
Reverted in https://trac.webkit.org/changeset/285045/webkit This patch makes Twitter CPU usage 100%.
Antti Koivisto
Comment 15 2021-11-03 02:54:32 PDT
Comment on attachment 441350 [details] Patch for landing View in context: https://bugs.webkit.org/attachment.cgi?id=441350&action=review > Source/WebCore/rendering/RenderFlexibleBox.cpp:1012 > + m_child.mutableStyle().setLogicalHeight(Length(flexBasis)); This sort of hacks are not ok.
Sergio Villar Senin
Comment 16 2021-11-10 02:35:38 PST
Sergio Villar Senin
Comment 17 2021-11-11 01:42:26 PST
zalan
Comment 18 2022-05-04 08:59:57 PDT
This broke the IRS payment page. see bug 240068.
Note You need to log in before you can comment on or make changes to this bug.