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
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
