I fail to reproduce this on either stable or ToT on OS X. I don't see any abnormally long layouts either when loading the page or when "clicking around".

You say this is a regression, any idea when it started? 

The massive layout in the trace is probably triggered by hit-testing. 
I can see this issue on M53 but not on M51 so it is a regression.

I have also attached  a devtools capture showing a 1.5 second layout during
scroll update. Some layout expert should take a look perhaps.

Deleted: TimelineRawData-20160609T133030.zip 13.6 MB

TimelineRawData-20160609T133030.zip 13.6 MB Download

I'm still seeing this in Canary on OS X, codesearch is unusable, it locks up constantly.

I just build Content Shell locally on OS X, the page locks up and doesn't respond, and as you scroll or try to select text it keeps locking up again.

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Document.cpp?sq=package:chromium&rcl=1465802517&l=5391

I loaded in Canary and Chrome gave the "Tab not responding" dialog.

Page loads fast in 51.0.2704.84, so this is a regression.

Could you please outline the steps needed to reproduce this?
No matter what I select, click or drag I cannot get either 52 or 53 to become unresponsive or trigger layouts longer than ~200 ms during load or ~50ms once loaded. 

I just load the page, and then I try to click a link or select text, the whole page seems to become frozen for several seconds.

Please add OS labels release blockers.

The traces clearly indicate that layout is slow; so I'm removing the Blink>Input>HitTesting label since it does seem the issue is solely in the layout camp. I've CC'd myself as I think this issue needs to be addressed soon.

I just did a local build and I see several multi second layouts, a profile in Instruments says:

Running Time	Self (ms)		Symbol Name
76074.0ms   83.3%	0.0	 	 blink::LayoutFlexibleBox::computeNextFlexLine(WTF::Vector<blink::LayoutBox*, 0ul, WTF::PartitionAllocator>&, blink::LayoutUnit&, double&, double&, double&, blink::LayoutUnit&, bool)

When loading https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Document.cpp?sq=package:chromium&dr=C&rcl=1466695104&l=3878

then select some text around the highlighted line and drag your mouse up and down to rapidly select more text and unselect text. Then try scrolling. You'll see huge hangs around page load.

Is this a flexbox bug?

Deleted: huge-layouts.png 149 KB

	huge-layouts.png 149 KB View Download

Oh hmm, that could be related to  bug 621644 ? That one is now fixed, so
maybe this will be better now too.

esprehn@: Can we get an update on this issue as per C#12.

OK, I ran a profile on trunk (plus https://codereview.chromium.org/2056043002/)

Now, 59% of the time is spent in Javascript code. 23% is spent in Flexbox layout, largely in the flex items' layoutIfNeeded. Only 4% is now spent in computeNextFlexLine.

 Issue 619883  has been merged into this issue.

I'll check my macbook tonight, this doesn't seem to lockup for several seconds on my desktop MacPro now though.

esprehn@ : Gentle ping..! Could you please update further on this.

Looks fixed to me!

OK, so it seems this was fixed by some combination of  bug 621644  and  bug 617792 

All of the fixes are in 53, but only some were merged to 52.