Bug 204031 – First layout and paint blocks sometimes blocks until document finishes parsing

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Layout and Rendering

[Ben Nham]

Created attachment 383178 [details]
first paint blocked test case

In some cases, the first layout and paint is throttled until the main document is finished parsing. The most common way this can happen is if someone creates a document with a large <script> (without defer or async) at the end of the document. Since the script can modify the document, the document won't finish parsing until the script has downloaded and then executed.

I've attached a test case that illustrates this. Run it with `server.py 8081` and then load http://localhost:8081/index.html. Firefox and Chrome render the page instantly, while Safari blocks for 10 seconds until the script finishes downloading and executing before rendering.

It looks like what happens here is that Document::shouldScheduleLayout only schedules an async layout if the FrameView::isVisuallyNonEmpty() returns true:

```
bool Document::shouldScheduleLayout()
{
    ...
    if (page() && page()->chrome().client().layerFlushThrottlingIsActive() && view() && view()->isVisuallyNonEmpty())
        return false;
```

FrameView::isVisuallyNonEmpty() returns a cached flag:

```
bool isVisuallyNonEmpty() const { return m_isVisuallyNonEmpty; }
```

This cached flag is updated from `FrameView::fireLayoutRelatedMilestonesIfNeeded`. We call `fireLayoutRelatedMilestonesIfNeeded` in three cases:

1. When the document finishes parsing (`Document::setParsing(false)`)
2. Periodically from the progress timer (`FrameView::loadProgressingStatusChanged()`). However there is a gate here which causes us to only fire the layout milestone if the frame is *completely* loaded (main resource and all subresources), so this actually does nothing in this test case.
3. After a layout in `FrameView::performPostLayoutTasks`. However, this will only fire if style recalc goes down the sync layout path, which it doesn't in this case.

I talked to @zalan about this and thinks it would probably be pretty easy to fix by updating the flag when the main runloop goes idle after a style recalc, as long as we agree that this is the correct behavior.

[Radar WebKit Bug Importer]

<rdar://problem/57039427>

[Simon Fraser (smfr)]

> when the main runloop goes idle after a style recalc
Please think about this in terms of HTML Event Loop, which might delay style recal until "update the rendering" time.

[Ben Nham]

I don't think my original test case was quite right, as this behavior doesn't seem to reproduce easily. I think some of the blocking I saw was simply the *server* being blocked handling a previous delayed request, since my original test case was a single-threaded server. So I'll have to take a closer look at this on Monday.

[Ben Nham]

The layout of the test case is unnecessarily delayed by 250 ms, which should be fixed by https://bugs.webkit.org/show_bug.cgi?id=208285. Duping to that.

*** This bug has been marked as a duplicate of bug 208285 ***