Bug 208500 - [first paint] visually-non-empty state should match FCP spec
Summary: [first paint] visually-non-empty state should match FCP spec
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 208482 208501 209895
Blocks: 78011
  Show dependency treegraph
 
Reported: 2020-03-02 23:32 PST by Noam Rosenthal
Modified: 2020-04-14 10:51 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Noam Rosenthal 2020-03-02 23:32:56 PST
Currently visually non-empty state differs from FCP spec in the following ways:
- It can be triggered by an empty canvas
- It does not get triggered by background images
- It has a pixel/character threshold, while FCP doesn't
- It's triggered when the page is ready with no pending requests (this is meaningful only for FCP reporting)

According to an email thread on webkit-dev, we should make an effort to match the spec and the implementation.
Comment 1 Geoffrey Garen 2020-04-13 11:10:55 PDT
Note: In cases where the spec and the implementation differ, we need to consider suggesting a change to the spec in order to match the implementation. It's not necessarily good to change the implementation to match the spec, if doing so would make painting worse.

Specifically, I'm skeptical about these item:

- It has a pixel/character threshold, while FCP doesn't

I'm not sure we want to paint in cases where painting would only render a few pixels; to many users, this may seem like a "flash of white", which can be bothersome just like a "flash of unstyled content".

- It's triggered when the page is ready with no pending requests (this is meaningful only for FCP reporting)

I'm pretty sure we want to paint in cases where there's nothing left to load. Though I don't remember the specifics, I remember we faced some cases where the entire contents of the webpage were too insignificant to trigger any painting according to our VNE heuristics, but we still needed to make sure to paint at page load done time, otherwise, we would never paint.
Comment 2 Geoffrey Garen 2020-04-13 11:12:02 PDT
(These two items do seem good to fix, at first glance):

- It can be triggered by an empty canvas
- It does not get triggered by background images
Comment 3 Noam Rosenthal 2020-04-13 11:52:42 PDT
(In reply to Geoffrey Garen from comment #2)
> (These two items do seem good to fix, at first glance):
> 
> - It can be triggered by an empty canvas
This was already fixed

> - It does not get triggered by background images
There's a patch for this waiting to be reviewed for quite a while...
https://bugs.webkit.org/show_bug.cgi?id=208501
Comment 4 Noam Rosenthal 2020-04-13 12:01:47 PDT
(In reply to Geoffrey Garen from comment #1)
> Note: In cases where the spec and the implementation differ, we need to
> consider suggesting a change to the spec in order to match the
> implementation. It's not necessarily good to change the implementation to
> match the spec, if doing so would make painting worse.
We've had a lot of spec discussions about those differences in the 6 weeks since this comment, and I think we got to a good middle ground and Google had also modified their implementation to conform. For what was left as implementation changes, see rniwa's comment: https://bugs.webkit.org/show_bug.cgi?id=78011#c7. All of this, apart from https://bugs.webkit.org/show_bug.cgi?id=208501 is done.

> 
> Specifically, I'm skeptical about these item:
> 
> - It has a pixel/character threshold, while FCP doesn't
> 
> I'm not sure we want to paint in cases where painting would only render a
> few pixels; to many users, this may seem like a "flash of white", which can
> be bothersome just like a "flash of unstyled content".
The current pixel/character heuristic raise a lot of questions... For example, what does a "few pixels" mean? Currently the pixels of an image are calculated by its intrinsic size, but in some cases it may cover the whole screen if it's extended by CSS. Also a page might show 10 characters of logo and we wouldn't show it because it's less than 200... FCP in that case is less heuristic - if there's anything contentful and potentially visible in the document then the paint is contentful.

But for now, as I understood what was agreed (see above comment link) is that FCP doesn't count pixels/characters but VNE would still block painting

> 
> - It's triggered when the page is ready with no pending requests (this is
> meaningful only for FCP reporting)
> 
> I'm pretty sure we want to paint in cases where there's nothing left to
> load. Though I don't remember the specifics, I remember we faced some cases
> where the entire contents of the webpage were too insignificant to trigger
> any painting according to our VNE heuristics, but we still needed to make
> sure to paint at page load done time, otherwise, we would never paint.

Yes. In this case, FCP might never trigger. I think this is OK, and was discussed on the spec group. FCP may be used to discover bugs, but of course WebKit should display the page in this case.
Comment 5 Geoffrey Garen 2020-04-13 20:47:44 PDT
> The current pixel/character heuristic raise a lot of questions...

Indeed!

> But for now, as I understood what was agreed (see above comment link) is
> that FCP doesn't count pixels/characters but VNE would still block painting

Hmmm... does that comment suggest that it's OK to report FCP even if we have not painted? Seems like that might mislead web developers, if they trigger the case where there's a difference.

> > - It's triggered when the page is ready with no pending requests (this is
> > meaningful only for FCP reporting)
> > 
> > I'm pretty sure we want to paint in cases where there's nothing left to
> > load. Though I don't remember the specifics, I remember we faced some cases
> > where the entire contents of the webpage were too insignificant to trigger
> > any painting according to our VNE heuristics, but we still needed to make
> > sure to paint at page load done time, otherwise, we would never paint.
> 
> Yes. In this case, FCP might never trigger. I think this is OK, and was
> discussed on the spec group. FCP may be used to discover bugs, but of course
> WebKit should display the page in this case.

Sounds good!
Comment 6 Noam Rosenthal 2020-04-14 00:10:41 PDT
(In reply to Geoffrey Garen from comment #5)
> > The current pixel/character heuristic raise a lot of questions...
> 
> Indeed!
> 
> > But for now, as I understood what was agreed (see above comment link) is
> > that FCP doesn't count pixels/characters but VNE would still block painting
> 
> Hmmm... does that comment suggest that it's OK to report FCP even if we have
> not painted? Seems like that might mislead web developers, if they trigger
> the case where there's a difference.
No, in any case in WebKit FCP would also be blocked by VNE. It means that in some cases in WebKit FCP would happen a bit later than what's in the spec because of this blocking. This meta-bug has tried to reduce these cases to a minimum, and now since the dependencies are closed, the only cases where VNE would block FCP reporting are where the pixel-count/character-count is below the threshold.
Comment 7 Geoffrey Garen 2020-04-14 10:42:45 PDT
Got it. Thanks!
Comment 8 Noam Rosenthal 2020-04-14 10:51:36 PDT
This was a meta-bug, and all of its dependencies are now met.