Re: Frame timing API question

On Mon, May 9, 2016 at 12:03 PM Nat Duca <nduca@google.com> wrote:

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

I think this is not much more powerful than what you can already do with
requestAnimationFrame+setTimeout. We'll probably be adding a callback at
this timing for ResizeObserver
<https://github.com/WICG/ResizeObserver/blob/master/explainer.md>.

That said, your proposal below still makes sense to me given that it would
allow you to also track slow paint.


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