Re: Frame timing API question

>
> Yes, that's essentially what we want.  That said, we'd be willing to
> settle for something slightly less than "the item is painted on screen" as
> we know :visited is an issue. For example, it'd be reasonable to get a
> callback when the element is laid out an is about to be painted. I'm pretty
> sure this can be done very hackily using rAF + triggering layout on our
> own. Maybe we could use IntersectionObserver to accomplish this as well.
>

I think an after-layout callback would still leak :visited --- the attack
here is sniffing browser history by changing urls and then waiting for a
frame to be created --- based on the variations in the paint times, you can
guess :Visited.

Here's a question. Since y'all operate at a giant scale, what if we made
this be more of a "something bad happened?

element.requestCallbackWhenPutOnScreenSlowly(cb) --- we would internally
start monitoring but would only call cb if the element was put onscreen in
>250ms. That'd indicate that you had a responsiveness problem. At scale,
you'd be able to tell if you had a problem, still. You wouldn't have fine
grained timing, but it'd be a smoke detector, which would be better than
nothing. Then, over time as we understand :visited we could come back and
try to get something more continuous...