When previous records of container timing should be invalidated?

[jdapena]

There are several scenarios where changes in the containertiming attributes changes may have effect on the events generated for container timing:

• When containertiming is removed from a node.
• When the containertiming identifier changes.
• When the nesting policy changes for a node.

What should we do in each case for the events that may have been collected before the attribute change?

[jdapena]

My proposal:

• On first two casees (container timing removed, or identifier change), we should likely just drop the previous records.

About nesting policy, I think we can also discard previous records as, otherwise, implementation would need to track which paints are coming from nested paints. So, for simplicity (and making implementations easier), my proposal is also discard previous records when nesting changes.

[jasonwilliams]

For the first two, I would like to know how that interacts with PerformanceObserver.takeRecords() as that would make use of container timing entries. My guess is this would empty those records out from the same list so someone calling takeRecords would not receive those events.

Is there an example of other scenarios where we remove entries?

About nesting policy, I think we can also discard previous records as, otherwise, implementation would need to track which paints are coming from nested paints.

Is this dropping all container timing entries on change? Or do you mean any nested events (in which case the implementation will need to keep track of which entries it can drop anyway?)

[jdapena]

For the first two, I would like to know how that interacts with PerformanceObserver.takeRecords() as that would make use of container timing entries. My guess is this would empty those records out from the same list so someone calling takeRecords would not receive those events.

I don't think we want to modify entries already generated and buffered. Because that would break the case where we intentionally remove containertiming to stop receiving new events. What I think should not happen is that new paints after that would reuse information from previous times containertiming was set. The way to do that is just dropping previous information.

So I see here we need to be careful with wording (I was not). One thing is the information we use to create new entries (already painted area, intersection rect, etc), and another the entries already created, but still not delivered to the user.

What I propose is wiping the information used to create new entries when DOM changes. So, already created entries are still there and available, but new paints will not reuse previous information.

Is there an example of other scenarios where we remove entries?

About nesting policy, I think we can also discard previous records as, otherwise, implementation would need to track which paints are coming from nested paints.

Is this dropping all container timing entries on change? Or do you mean any nested events (in which case the implementation will need to keep track of which entries it can drop anyway?)

We would just remove the data pending to be processed to create entries. It is more intended to provide clarity that we are not expected to somehow be able to show coherent information when we change the nesting mode. Entries after the change would work as if containertiming was unset and set.