Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Automatically adding ccs based on suspected regression changelists:

Use new intrinsic content height when computing min-height: min-content by cbiesinger@chromium.org - https://chromium.googlesource.com/chromium/src/+/ed528b2c5a2eef209222118fc34b7d9e325c9939

Absolute positioned child with percent should include containing block padding by deokjin81.kim@samsung.com - https://chromium.googlesource.com/chromium/src/+/9908f45b70b65fc242e050d33c67294fe870a1cb

If this is incorrect, please apply the Test-Predator-Wrong-CLs label.

cbiesinger@/deokjin81.kim@, could someone please look into this?

I looked briefly into this, neither of those changes are likely to cause this. I am surprised this is a regression, I would have thought this is just a regular stack overflow due to a deep DOM. But I ran out of time to investigate this, cc'ing Morten in case he has time to look at it while the US is on holiday.

The DOM is indeed deep. I haven't seen this particular type of stack overflow problem, though. It happens because the DOM tree isn't deep enough to cause stack overflow when building the layout tree, nor when descending into the layout tree via UpdateLayout(), and so on. However, inside LayoutTable::UpdateLayout() there's a call to AvailableLogicalHeight(), which might recurse all the way back up to the root (if no heights on the way are non-auto, at least). So when you have first pushed all the UpdateLayout() calls on the stack all the way down to the deeply nested table, you go ahead and push all the ContainingBlockLogicalHeightForContent(), AvailableLogicalHeightUsing(), etc. all the way back up to the root.

I think this may be worth fixing, although it does require the DOM to be here-be-dragons deep. It causes a performance problem if you have a table somewhere deep in an tree with all auto-height layout objects.

Attaching a simplified test case that crashes on my machine (Linux).

Deleted: tc.html 902 bytes

tc.html 902 bytes View Download

This behavior got introduced by https://codereview.chromium.org/2701163002

I think we need to use something other than AvailableLogicalHeight(), since we risk walking all the way to the root, returning the viewport height, which in any case is a meaningless value in this case. I suppose all we want to know in this particular case, is whether the extrinsic height of the table is going to change.

So do we just limit the check to cases where the table is percent height or is there a better way?

That could work, in addition to vh and vw units, perhaps? And only if it's not marked for layout?

Not too elegant, though. The flag name table_height_changing becomes pretty imprecise then.

Why does AvailableLogicalHeight() walk all the way to the root if height is auto and return the viewport height? How would that ever be the right answer?

For what it's worth, vh/vw get resolved by the CSS parser and show up as Length(Fixed) in the ComputedStyle

But I'm confused, if this is just used for percentage resolution, auto heights shouldn't have to walk up to the root since they can't be resolved in standards mode?! It seems like you may want AvailableLogicalHeightForPercentageComputation()?

ClusterFuzz testcase 6039379352223744 is still reproducing on tip-of-tree build (trunk).

If this testcase was not reproducible locally or unworkable, ignore this notification and we will file another bug soon with hopefully a better and workable testcase.

Otherwise, if this is not intended to be fixed (e.g. this is an intentional crash), please add ClusterFuzz-Ignore label to prevent future bug filing with similar crash stacktrace.

"Why does AvailableLogicalHeight() walk all the way to the root if height is auto and return the viewport height? How would that ever be the right answer?"

I think it's the right answer when you have a percentage height or any other height that needs to be resolved against the height that's available isn't it?

eae: Is this definitely a wontfix? 

Maybe it's reasonable to continue past an ancestor with non-definite height in quirks mode under some circumstances, but certainly not in strict mode.

 Issue 795495  has been merged into this issue.

But why does this not use AvailableLogicalHeightForPercentageComputation, wouldn't that be more correct? I'm going to reopen this bug to address that question...