On Thu, Feb 27, 2020 at 12:46 PM Noam Rosenthal <n...@webkit.org> wrote:

> On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss <y...@yoav.ws> wrote:
>> On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa <rn...@webkit.org> wrote:
>>> I don't think we should do that. For starters, Chrome's painting
>>> strategy while loading a web page is very different from that of Safari /
>>> WebKit. We would freeze the painting of the previous page at the moment a
>>> new navigation is committed, and we wouldn't update the painting until the
>>> destination page has a meaningful content in it. This is a very much
>>> different from Chrome's model where the moment a new navigation is
>>> committed, Chrome will show a blank page then start incrementally painting
>>> the page throughout the navigation.
>> Body background color is still painted before any contentful paint... Is
> this a bug?
> Also, a web page might not have content at all (e.g. a bunch of divs with
> bgcolors). Would webkit not render that web page at all?

It seems like the code in FrameView does this:

    // Ensure that we always fire visually non-empty milestone eventually.

    *if* (finishedParsingMainDocument && frame().loader().isComplete())

        *return* *true*;

I suggest splitting this to two milestones - the current one, that triggers
when the main document finished loading, and another one that only triggers
when content has actually been painted (which may never happen). I think
this would be a good split for first-paint/first-contentful-paint in WebKit.

But let's take the specifics to Slack/bugzilla?
webkit-dev mailing list

Reply via email to