Should LoAF emit when there is a long blocking task but no "paint"

[tunetheweb]

Should LoAF emit when there is a long blocking task but no "paint"?

Often these result in a high INP but no LoAF giving details as to why. Of course best practice would be to have a paint of some sort acknowledging the interaction but there's plenty of examples were that's not the case (including a "no-op" click while the main thread is busy whether this is nothing to update).

Demo illustrating this: https://loaf-tester.glitch.me/

[mmocny]

LoAF does fall back to reporting just "long task", and as you note in the demo, the first key interaction does report a LoAF.

I don't think this has anything to do with paints. For some reason the second long task isn't reported.

[tunetheweb]

OK sounds like a Chromium Bug so raised this: https://issues.chromium.org/issues/346918311

LoAF does fall back to reporting just "long task"

Is this explicitly documented anywhere in the spec? Can't see it. Should it be?

[mmocny]

The second paragraph of the intro in this repo:

Long animation frames (LoAF), as a revamp of longtasks, aim to assist with that: a LoAF is an indication that at a particular point in time, the browser was congested, in such a way that it took a long time from the beginning of a task until updating the rendering (or until the point where it was clear that no render was necessary).

(emphasis mine)

Then the section that introduces LoAF says:

It's the time measured between when the main thread started doing any work (see startTime here), until it is either ready to paint or idle (has nothing to do).

And of course, its well specced:

• This english-language paragraph summarizes
• I think this bit step 6 is it:

If the user agent believes that updating the rendering of document’s node navigable would have no visible effect, then report frame timing given document and return.

[mmocny]

I just did some test in Canary and found that when this symptom happens, all of LoAF measurement is not working at all-- even for tracing.

So, it's not that LoAF is choosing not to emit a performance entry, its that we are failing to observe LoAF durations.

I'll have to run a custom build to see what animation frame timing monitor is observing here. (e.g. are we still observing tasks but for some reason the attribution is getting accumulated forever without flushing? Do we stop observing? Is the monitor destroyed/detached?)