New issue
Advanced search Search tips

Issue 667282 link

Starred by 1 user
Status: Available
Owner: ----
Cc:
atotic@chromium.org
szager@chromium.org
mstensho@chromium.org
cbiesin...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Vertical scrollbar doesn't contribute to shrink-to-fit container width in initial layout pass

Reported by msten...@opera.com, Nov 21 2016 
It looks like the forced re-layout with PaintLayerScrollableArea::FreezeScrollbarsScope in layoutBlockFlow() isn't always triggered when it should.

The reason is that preferredLogicalWidthsDirty() is true all the time e.g. if "width" is "fit-content". One would perhaps expect updateLogicalWidthAndColumnWidth() to always clear the PreferredLogicalWidthsDirty flag, but this only happens if computePreferredLogicalWidths() is involved. In the case of "width:fit-content", it's computeBlockPreferredLogicalWidths() that's called, which doesn't reset the flag (well, it's a const method...)

In the attached test case, if you resize the window (to trigger another layout pass), it will pass.
tc.html
295 bytes View Download

Comment 1 by e...@chromium.org, Oct 26

Cc: szager@chromium.org
Owner: ----
Status: Available (was: Assigned)

Comment 2 by mstensho@chromium.org, Dec 10

Cc: cbiesin...@chromium.org atotic@chromium.org mstensho@chromium.org
This also affects LayoutNG. scrollbars/auto-scrollbar-fit-content.html fails in LayoutNG because of this. It doesn't fail in legacy layout, though, because the float in the test somehow triggers sufficient amounts of layout passes (in legacy, but not in NG). Changing the float in the test from "float:left" to "width:fit-content" makes the problem reproducible in legacy layout too.

Note that Blink is the only engine that actually makes room for auto scrollbars that might appear when calculating min/max preferred widths.
►

Sign in to add a comment