[first paint] visually-non-empty state should match FCP spec

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Noam Rosenthal]

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.

[Geoffrey Garen]

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.

[Geoffrey Garen]

(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

[Noam Rosenthal]

(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

[Noam Rosenthal]

(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.

[Geoffrey Garen]

> 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!

[Noam Rosenthal]

(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.

[Geoffrey Garen]

Got it. Thanks!

[Noam Rosenthal]

This was a meta-bug, and all of its dependencies are now met.