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