Able to reproduce the issue on windows 7 using chrome version 60.0.3112.10 .Issue not reproducible on Mac 10.12.4

Using the per-revision bisect providing the bisect results,
Good build:60.0.3080.0 (Revision:466837).
Bad build:60.0.3081.0 (Revision:467177).

You are probably looking for a change made after 466933 (known good), but no later than 466934 (first known bad).

CHANGE-LOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/9e8f21af25c5425136583d7658850e4a7db2146e..76e307f44292b2999535aa8c5605cfd9129e9c12

From the CL above, assigning the issue to the concern owner

@shoon.kim: Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-Url: https://codereview.chromium.org/2828453002
Note :Able to reproduce the issue in Win 10.0,Ubuntu 14.04 & Mac 10.12.3 and Able to reproduce in latest Canary #61.0.3117.0
Unable to find the "shoon.kim" mail id.So assigning to reviewer.

Incorrectly assigned.

Easy to reproduce. Reverting the CL makes the problem go away. I'm only going to work sporadically tomorrow and then be off until Tuesday next week. In the meantime, a simplified test case would help a lot. I don't really know where to look. I mean, I can inspect elements in the small window that appears, but it looks like the window itself is shrunk-to-fit. Where does that happen? Someone who knows how extensions work might know?

The bug seems to be triggered by code in LayoutBlock::UpdateBlockChildDirtyBitsBeforeLayout(), which marks a child's preferred logical widths as dirty if the child NeedsPreferredWidthsRecalculation(). This is bad, because calculating preferred logical widths and updating layout happens in slightly different phases. Calculating preferred logical widths is driven from some object that needs it (anything shrink-to-fit-ish, really). We then calculate the preferred logical widths of each object in then entire subtree, and then proceed with layout. LayoutBlock::UpdateBlockChildDirtyBitsBeforeLayout() is called during layout. If we here mark the preferred logical width of some object dirty, we risk not marking it clean again (because marking clean happens during preferred widths calculation, and we may be done with that already!). If something inside such an object (that gets its preferred widths marked dirty during layout) changes afterwards (by adding or removing content, for instance), we'll fail to recalculate the preferred logical widths, because the machinery for marking preferred widths as dirty will terminate when it reaches some object in the ancestry that has already been marked dirty.

I still don't quite know what's going on in the extension, and I don't know how to find out. I'll now try to come up with some tests. In theory it should be possible to come up with a test case that would also fail without the blamed CL applied. As NeedsPreferredWidthsRecalculation() gets more and more reasons for returning true (like in the blamed CL), the worse this bug will get. I tried to change it to always return true (which really should be harmless), and then Acid2 broke. :)

Test case that also fails before the blamed CL landed. This is caused by what LayoutBlock::UpdateBlockChildDirtyBitsBeforeLayout() does regarding dirty-marking of preferred widths during layout. This is most likely a very old bug.

Deleted: tc-oldbug.html 407 bytes

tc-oldbug.html 407 bytes View Download

Test case that started to fail with the blamed CL. To sum up: the more frequently we return true from NeedsPreferredWidthsRecalculation(), the more damage is done by the code in UpdateBlockChildDirtyBitsBeforeLayout().

Deleted: tc.html 414 bytes

tc.html 414 bytes View Download

This bug (illustrated by tc-oldbug.html) was essentially introduced 10 years ago, with this fix: https://bugs.webkit.org/show_bug.cgi?id=13373

(of course it may have been okay to do a thing like that back then, but certainly not anymore)

Just to update the latest behavior,

Able to reproduce the issue on Win-10 using latest canary #61.0.3122.0.

Thanks...!!

Friendly ping! still able to reproduce the issue on Win 10.0 using latest chrome version canary #61.0.3127.0.

mstensho@ Could you please look into this issue.

Thanks!

Fix ready to land (just waiting for the tree to turn green again):

https://chromium-review.googlesource.com/c/527640/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4aad5b967dc3c9405565f8a7274d2ff9c37e6405

commit 4aad5b967dc3c9405565f8a7274d2ff9c37e6405
Author: Morten Stenshorne <mstensho@opera.com>
Date: Mon Jun 12 14:42:54 2017

Better handling of min/max widths that depend on the containing block.

This is about how we behave when NeedsPreferredWidthsRecalculation()
is true. This is a rather rare situation, and also an unfortunate one,
since min/max width calculation should be strictly bottom-up.

If we mark min/max widths of an object as dirty, we need to guarantee
that they're actually going to be recalculated. Otherwise, if the
object is left around with dirty min/max widths, it will block
subsequent min/max dirtying of any descendant. We also need to make
sure that if we mark min/max widths as dirty due to
NeedsPreferredWidthsRecalculation(), we also need to mark the min/max
widths of every child with the same issue as dirty, recursively, since
any layout change may have affected the min/max widths there too.

Documented NeedsPreferredWidthsRecalculation(). Added one test that
has been failing for ages, and one that started to fail because of the
bug referenced. Both pass now.

BUG= 728548 

Change-Id: I8b9325ba20a6da2329d28d21a6eca6bc1aa36c06
Reviewed-on: https://chromium-review.googlesource.com/527640
Reviewed-by: Stefan Zager <szager@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@opera.com>
Cr-Commit-Position: refs/heads/master@{#478616}
[add] https://crrev.com/4aad5b967dc3c9405565f8a7274d2ff9c37e6405/third_party/WebKit/LayoutTests/fast/css-intrinsic-dimensions/change-inside-percent-height.html
[add] https://crrev.com/4aad5b967dc3c9405565f8a7274d2ff9c37e6405/third_party/WebKit/LayoutTests/fast/css-intrinsic-dimensions/change-inside-percent-padding.html
[modify] https://crrev.com/4aad5b967dc3c9405565f8a7274d2ff9c37e6405/third_party/WebKit/Source/core/layout/LayoutBlock.cpp
[modify] https://crrev.com/4aad5b967dc3c9405565f8a7274d2ff9c37e6405/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/4aad5b967dc3c9405565f8a7274d2ff9c37e6405/third_party/WebKit/Source/core/layout/LayoutBox.h

[Auto-generated comment by a script] We noticed that this issue is targeted for M-60; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-60 label, otherwise remove Merge-TBD label. Thanks.

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Removing "Merge-TBD" as M60 merge is requested at #19 & #20.

Issue 730862 has been merged into this issue.

TPMs, this is also affecting an internal tool (https://crbug.com/726502). Can we merge into 60?

Tested this issue on latest linux i.e., 61.0.3132.0 dev with steps mentioned in comment#0 and is no longer reproducible

Hence adding TE Verified labels

RB-Stable bug, bug regression. Approving merge to M60. 

Using branch 3112.

Landed: https://chromium.googlesource.com/chromium/src/+/d3fee8aafedd9fda1b9b9e4542f4451455ceeb5c

I think I failed to do the right thing here, for the merge (I expected feedback from some bot). Help? :) Wrong branch?

Thanks for taking care of the merge.

I think you did the right thing and the bots are just on holiday. If you look on the branch's changelog, the above merge is there: https://chromium.googlesource.com/chromium/src/+log/60.0.3112.32..60.0.3112.40?pretty=fuller&n=10000