Bisected to these two commits: https://chromium.googlesource.com/chromium/src/+log/679ec32b1ab9d0fe56cfec0642b7cadffc815beb..d892f9592860691ae9a782c12260c94ed6bd1a63

Of those, only this CL could possibly be involved: https://codereview.chromium.org/2680943004

yosin@, do you know why the CL to change how FrameSelection works could possibly be changing the rendering scheduling (or layout) while loading?

The test page in question doesn't have any content-editable elements or anything that would include a carat so nothing in the CL is jumping out at me but manually bisecting on a few different OS's and systems all come back to the same range.

Trace attached with a bunch of the blink, net and render categories enabled.

The actual loading starts at 2,427ms.

Commits are unblocked at 2,431ms.

The Layout tree looks to be built as expected and even cc's LayerTreeHostImpl appears to be updating.

As best as I can tell, the compositor is rasterizing the times and even calls through to RenderWidget::DidCommitAndDrawCompositorFrame at 2,456ms.

Deleted: trace_Mon_Apr_03_2017_12.46.26_PM.json.gz 5.4 MB

trace_Mon_Apr_03_2017_12.46.26_PM.json.gz 5.4 MB Download

This sounds like you didn't really disable the old FOUC system, that means an updateLayoutIgnorePendingStylesheets will compute the style and layout, but suppress painting to avoid FOUC. FrameSelection is doing updateLayoutIgnorePendingStylesheets here so we end up painting all white until the sheet loads and issue a full screen invalidation.

You need to disable the whole old system so we stop painting white and pretending stuff isn't ready.

Paint suppression:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp?rcl=3619dab216f9b1e431f5b271fa668eaee0f95112&l=32

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp?rcl=3619dab216f9b1e431f5b271fa668eaee0f95112&l=199

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/paint/BlockFlowPainter.cpp?rcl=3619dab216f9b1e431f5b271fa668eaee0f95112&l=22

System that triggers this you need to disable:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Document.cpp?type=cs&l=2271

I think your feature always had this problem, but Yosin's patch started making us force a second layout in the IgnorePendingStylesheets mode on every frame (which is also a bug), which is the same as if you had JS doing .offsetTop every frame.

#c1, >yosin@, do you know why the CL to change how FrameSelection works could possibly be changing the rendering scheduling (or layout) while loading?

My patch[1] makes FrameSelection to work on clean layout tree. Before the patch[1],
FrameSelection uses dirty layout tree and some functions in FrameSeleciton returns
wrong answer due by dirty tree.

[1] http://crrev.com/2680943004 Make FrameSelection to hold non-canonicalized positions

>#c1, The test page in question doesn't have any content-editable elements or anything that would include a carat so nothing in the CL is jumping out at me but manually bisecting on a few different OS's and systems all come back to the same range.

I attempt to remove redundant update layout but the  issue 372245 [1] blocks this.

[1]  http://crbug.com/372245  ⚐	LayoutTextTrackContainer::layout() should not modify DOM tree

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

commit 858a132b904074acf0782b1c1ab2d68a61cce899
Author: Patrick Meenan <pmeenan@chromium.org>
Date: Mon May 14 13:50:16 2018

Fixed the paint supression to track only render-blocking stylesheets.

This fixes the logic that updates style and layout to not consider
in-body CSS as render-blocking when the
CSSInBodyDoesNotBlockPaintEnabled experiment is enabled.

It also fixes the logic to also look at pending imports (which are
always render-blocking wether in body or head) and treat them
the same as render-blocking stylesheets.

It also removes the logic that would ignore pending stylesheets
deep in the style engine when HaveScriptBlockingStylesheetsLoaded
was called. It wasn't necessary because IsRenderingReady already
checks for the ignore flag and led to a lot of inconsistent logic.

This is an update of the unsbmitted CL from last year:
https://codereview.chromium.org/2823873002/

BUG= 707747 

Change-Id: Id88b945334d8d029a654e2619004b077b47055ab
Reviewed-on: https://chromium-review.googlesource.com/1053878
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Patrick Meenan <pmeenan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#558286}
[modify] https://crrev.com/858a132b904074acf0782b1c1ab2d68a61cce899/third_party/blink/renderer/core/css/style_engine.h
[modify] https://crrev.com/858a132b904074acf0782b1c1ab2d68a61cce899/third_party/blink/renderer/core/dom/document.cc
[modify] https://crrev.com/858a132b904074acf0782b1c1ab2d68a61cce899/third_party/blink/renderer/core/dom/document.h
[modify] https://crrev.com/858a132b904074acf0782b1c1ab2d68a61cce899/third_party/blink/renderer/core/exported/web_meaningful_layouts_test.cc

Current canary with yesterday's fix is working correctly.