Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.89 Safari/537.36

Same problem on Mac, with more complex layout, also overflow: auto for table style freezes tab. 

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.101 Safari/537.36

Confirming on Mac OS X, today's update of Chrome - both the example link, and an external page freeze the tab. Other tabs unaffected, mouse cursor normal, and after trying to close the tab, it takes a while to respond. Confirming that changing away from "overlow: auto" on our nested layout prevents the problem.

And it's probably a regression, since we had the same problem on the same page appear on Chrome update 2-3 months ago, and then went away by itself on subsequent Chrome update.

Able to reproduce the issue on the latest canary(55.0.2855.0) and the latest stable(53.0.2785.101) on Windows-10, Mac OS 10.11.6 and Linux Ubuntu 14.04.

This is a regression issue broken in M-53.

Last good build: 53.0.2754.0
First bad build: 53.0.2756.0 (No trunk build for 53.0.2755.0)

Changelog:
==========
https://chromium.googlesource.com/chromium/src/+log/a0f4b5051a2ef87f7de7cb469fe87d781cc0ab35..fb0fd2cfd895efb50f6645f2177d9bf0639451d6

Marking this as Stable blocker for M-53 in case there is any stable refresh.

eae@: Could you please take a look and check if https://codereview.chromium.org/2026073002 could be related to this.

Thank you!

Rebisected this on Windows and got the below bisect result:

https://chromium.googlesource.com/chromium/src/+log/1a3db4d18d2d8c243da9a7e4b8c30c709dbbf352..65c873e2440233e3b12242930190869a5fd90919

Looks to be related to https://codereview.chromium.org/1980103002.

This bug has been reported as M53 Stable blocker. We're planning Stable respin next week. Please have fix ready/merged to M53 branch 2785 by 3:00 PM PT on Monday (09/12/16).

That bisect information is bogus; root cause is this, or one of a few follow-on patches that came later:

https://codereview.chromium.org/1980103002

It's the overflow:auto in the broken page that puts layout into an infinite loop.

This probably shouldn't be a blocker, the reproduction is very difficult and fragile.

Moving to M-54.

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

commit 172acf68063a6e6dee7b55edc3e6c19171d0bf5d
Author: szager <szager@chromium.org>
Date: Sat Sep 10 01:29:58 2016

Freeze auto scrollbars while calculating table row height.

The cause of the infinite layout is that calcRowLogicalHeight
forces a child layout without size overrides, which causes auto
vertical scrollbars to change, which sets preferred width dirty.
At the time that calcRowLogicalHeight runs, layout is clean, so
auto scrollbars should already be in a stable state.

BUG= 644635 
R=dgrogan@chromium.org,esprehn@chromium.org

Review-Url: https://codereview.chromium.org/2328883003
Cr-Commit-Position: refs/heads/master@{#417792}

[add] https://crrev.com/172acf68063a6e6dee7b55edc3e6c19171d0bf5d/third_party/WebKit/LayoutTests/fast/table/row-height-recalc-terminates.html
[modify] https://crrev.com/172acf68063a6e6dee7b55edc3e6c19171d0bf5d/third_party/WebKit/Source/core/layout/LayoutTableSection.cpp

Verified the issue on windows 10, Ubuntu 14.04 and Mac 10.11.6 using chrome dev version ##55.0.2859.0 and observed that the fix is working as expected.

Attaching screenshot for reference.

Hence, adding the verified labels.

Deleted: 644635.PNG 58.3 KB

	644635.PNG 58.3 KB View Download

Your change meets the bar and is auto-approved for M54 (branch: 2840)

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

commit 5425fbfc405f835d58764fe9de1abc02e1860f42
Author: szager <szager@chromium.org>
Date: Tue Sep 13 18:03:07 2016

[M54] Freeze auto scrollbars while calculating table row height.

The cause of the infinite layout is that calcRowLogicalHeight
forces a child layout without size overrides, which causes auto
vertical scrollbars to change, which sets preferred width dirty.
At the time that calcRowLogicalHeight runs, layout is clean, so
auto scrollbars should already be in a stable state.

Cherry-picked from https://codereview.chromium.org/2328883003

BUG= 644635 
TBR=dgrogan@chromium.org,esprehn@chromium.org
NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2336323002
Cr-Commit-Position: refs/branch-heads/2840@{#332}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[add] https://crrev.com/5425fbfc405f835d58764fe9de1abc02e1860f42/third_party/WebKit/LayoutTests/fast/table/row-height-recalc-terminates.html
[modify] https://crrev.com/5425fbfc405f835d58764fe9de1abc02e1860f42/third_party/WebKit/Source/core/layout/LayoutTableSection.cpp

I totally disagree this is non-blocker. This issue crashes several production apps and no replacement for `overflow:auto` is possible.
The source example seems to work in Chrome 55.0.2860.0 canary, but this example with flexbox doesn't https://bugs.chromium.org/p/chromium/issues/detail?id=644450

Please re-consider this as a blocker. It breaks production application that impacts a couple of thousands of users at my company as well. I've tried several workaround but still unable to find a good one. I'm afraid that I'll get several SRs when more people getting v53.

This bug is indeed related to the one mentioned in comment #17, but the fix for this bug does not fix the other bug.

This bug -- and its fix -- affect only table layout, not flexbox.  Please verify that the fix for this bug, which is included in the current dev release , does indeed fix your production issues.  If so, then I'll request merge to the next M53 stable release.

If your production issue is instead related to flexbox, then please chime in on that bug.

Thank you @szager

I've verified in Canary (55.0.2860.0) that the issue is not resolved. So it could be the flex-box one that we have seen. I'll be following up on the other bug.

I would also vote for a blocker status as this bug is impacting several of our large enterprise customers who recently upgraded to Chrome 53 due to security fixes.  They are only able to use our application by viewing it in another browser for now.

We are trying to figure out which of our dependencies (large angular single page app) are responsible for injecting the css rule to see if we can temporarily remove it as an emergency hotfix.  When we tried just overriding the CSS rule, it severely broke the layout of our app.

If there are any suggested work-arounds, I'd be very happy to hear of them.

@ daniel.einspanjer: please verify that the fix for this bug fixes your site, as explained in comment #20.  If your issue is with flexbox rather than table, then this is the wrong bug to comment on.

I just downloaded Version 55.0.2861.0 canary (64-bit) and I was able to successfully navigate our production sites without hanging.

I tried my current install, Version 53.0.2785.101 (64-bit) with a fresh profile, and it still hangs.

I also downloaded the Dev and Beta installs, but I'm having trouble ensuring they are actually running.  When I check the chrome:version, it shows the same version as my current install.

Requesting merge to M53, as this is apparently affecting sites in the wild.

[Automated comment] Request affecting a post-stable build (M53), manual review required.

Removing the M53 merge request label.  I have a fix for the related bug ( crbug.com/644450 ) which is more general, and fixes this bug as well.  Once that fix lands in dev and looks good, I will request that it be merged into the current stable and beta branches.

We probably won't cut a new stable release of chrome just for the purpose of pushing out this fix; but the fix will be included in the next stable release, whenever that happens.

quick fix is overflow: auto; instead of scroll.

overflow: auto did not fix for my only overflow:visible;

@vita This is fixed now update Chrome https://bugs.chromium.org/p/chromium/issues/detail?id=644450

To avoid this bug you shouldn't use `overflow:auto` and perform manual scroll setup like

```
function setScroll(el) {
  el.style.overflowX = (el.scrollWidth > el.clientWidth ? 'scroll' : 'hidden');
  el.style.overflowY = (el.scrollHeight > el.clientHeight ? 'scroll' : 'hidden');
}
```

Thank you, I have confirmed that the problem has been fixed on both versions:
53.0.2785.143
54.0.2840.71 

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

commit 5425fbfc405f835d58764fe9de1abc02e1860f42
Author: szager <szager@chromium.org>
Date: Tue Sep 13 18:03:07 2016

[M54] Freeze auto scrollbars while calculating table row height.

The cause of the infinite layout is that calcRowLogicalHeight
forces a child layout without size overrides, which causes auto
vertical scrollbars to change, which sets preferred width dirty.
At the time that calcRowLogicalHeight runs, layout is clean, so
auto scrollbars should already be in a stable state.

Cherry-picked from https://codereview.chromium.org/2328883003

BUG= 644635 
TBR=dgrogan@chromium.org,esprehn@chromium.org
NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2336323002
Cr-Commit-Position: refs/branch-heads/2840@{#332}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[add] https://crrev.com/5425fbfc405f835d58764fe9de1abc02e1860f42/third_party/WebKit/LayoutTests/fast/table/row-height-recalc-terminates.html
[modify] https://crrev.com/5425fbfc405f835d58764fe9de1abc02e1860f42/third_party/WebKit/Source/core/layout/LayoutTableSection.cpp