Index: third_party/WebKit/Source/core/layout/LayoutGrid.cpp |
diff --git a/third_party/WebKit/Source/core/layout/LayoutGrid.cpp b/third_party/WebKit/Source/core/layout/LayoutGrid.cpp |
index 00436b95c574ea8221b85725c835a36ec99822cc..eb9934f3ef736831056c3d4eb5da7a48cdc0befd 100644 |
--- a/third_party/WebKit/Source/core/layout/LayoutGrid.cpp |
+++ b/third_party/WebKit/Source/core/layout/LayoutGrid.cpp |
@@ -280,6 +280,21 @@ void LayoutGrid::UpdateBlockLayout(bool relayout_children) { |
// resolve heights properly (like for positioned items for example). |
ComputeTrackSizesForDefiniteSize(kForColumns, available_space_for_columns); |
+ // We take the chance to store the intrinsic sizes as the track sizing |
+ // algorithm always compute them as part of its execution. Apart from saving |
jfernandez
2017/04/21 14:48:02
What do you mean with this sentence ?
svillar
2017/04/21 14:51:24
In order to compute the intrinsic sizes we have to
|
+ // an algorithm execution, it fixes the use case of computing the preferred |
jfernandez
2017/04/21 14:48:02
Why we save an algorithm execution with this chang
svillar
2017/04/21 14:51:23
Because we wouldn't have to call the algorithm lat
|
+ // logical widths *after* the layout process. Although not very common, this |
+ // happens in the Mac (content::RenderViewImpl::didUpdateLayout()) or under |
+ // some circumstances when grids are also flex items (crbug.com/708159). |
+ if (PreferredLogicalWidthsDirty()) { |
+ LayoutUnit scrollbar_width = LayoutUnit(ScrollbarLogicalWidth()); |
+ min_preferred_logical_width_ = |
+ track_sizing_algorithm_.MinContentSize() + scrollbar_width; |
+ max_preferred_logical_width_ = |
+ track_sizing_algorithm_.MaxContentSize() + scrollbar_width; |
+ ClearPreferredLogicalWidthsDirty(); |
+ } |
+ |
// 2- Next, the track sizing algorithm resolves the sizes of the grid rows, |
// using the grid column sizes calculated in the previous step. |
if (CachedHasDefiniteLogicalHeight()) { |