[Webkit-unassigned] [Bug 204031] New: First layout and paint blocks until document finishes parsing

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=204031

            Bug ID: 204031
           Summary: First layout and paint blocks until document finishes
                    parsing
           Product: WebKit
           Version: WebKit Local Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: nham at apple.com
                CC: bfulgham at webkit.org, simon.fraser at apple.com,
                    zalan at apple.com

Created attachment 383178

  --> https://bugs.webkit.org/attachment.cgi?id=383178&action=review

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20191109/2bb1c9f9/attachment-0001.htm>