Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users
Status: Fixed
Owner: ----
Closed: Oct 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

issue 79180

Sign in to add a comment
[css-grid] Different width of grid container between initial load and refresh
Project Member Reported by, Jul 15 2016 Back to list

If you open the following Layout Test [1]:

The first time the width of the first grid container is 110px, but if you resize the window or reload the page, the width is 120px.

We should investigate why we're getting different results depending on the layout.

I tried to create a reduced test case but it seems that I cannot reproduce it without the JavaScript involved on the test.

I managed to reproduce it inside JS Bin too (resize the output frame to see it):,output

Comment 1 by, Jul 29 2016
Status: Assigned
I've analyzed this issue and I found why it is behaving incorrectly. First of all we're talking about a grid container with intrinsic size, so we need to compute the preferred logical widths. Apart from that it also has orthogonal items. So this is what happens when we layout

1) orthogonal items are pre-laid
2) we compute the intrinsic size. For orthogonal items we use the values computed in the previous phase (which do not consider the existence of a grid)
3) we layout

So the thing is that during 1) we haven't executed any grid code yet so they don't have any grid area set (the override containing block logical sizes). This mean that orthogonal items would be laid out without any restriction coming from the tracks. In your example items in the second row won't obbey the fixed size of the row, so they will be laid out assuming that they have all the space they need.

For 2) we use the values computed in 1) as during intrinsic size computation layout is not permitted. This means that the intrinsic size of the grid will be wrong (as soon as we have at least 1 content sized track) because the orthogonal items were laid out without considering the track sizing restrictions.

Then we start 3) with a wrong value for the available width (because the width is fit-content so we use the intrinsic width computed in 2) ) leading to wrong inline sizes for the grid container and the grid columns.

Resizing the grid fixes the issue because it forces a new intrinsic size computation which will use the already set override sizes.
Project Member Comment 2 by, Oct 10 2016
The following revision refers to this bug:

commit 45a34a1a8f382bcaa36e8d1c58575f34f2832237
Author: jfernandez <>
Date: Mon Oct 10 21:36:11 2016

[css-grid] Clearing override sizes before running grid's layout logic.

Grid's layout logic manages two different override sizes; one it's
designed to implement the grid item's stretching behavior, identified
with the concept of 'overrideContentLogicalSize'; there is another
override size, known as overrideContainingBlockContentLogicalSize,
used to implement the Grid Area abstraction, which will behave as
the actual containing block of any grid item.

During grid's layout logic these override sizes are set according
to the CSS style rules. This affects how the grid container and its
children are going to be sized during layout. Grid Tracks sizing
algorithm depend on these override sizes.

In order to ensure that the tracks sizing algorithm produces the
same results when it's run consecutively several times, we need to
clear these override sizes and performs a layout of the affected grid
items. Otherwise, the affected items will return sizing values which
depend on the override values set in the previous layout, which in
some cases, like orthogonal flows, may change through different runs
of the sizing algorithm.

BUG= 628565 

Cr-Commit-Position: refs/heads/master@{#424250}


Status: Fixed
This issue should be FIXED now.
Sign in to add a comment