1271846 - Drop old FrameTiming interface added in bug 1191178

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Hiroyuki Ikezoe (:hiro)]

Unfortunately Frame Timing API has been completely changed.  I added two interfaces for the old Frame Timing API, but they are no longer valid.  We should remove them.

And I have no plan to implement Frame Timing API (bug 1158032) until we follow browser processing model[1].

[1] https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-8

Comment 1

[Hiroyuki Ikezoe (:hiro)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=51305abbc494

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

What do we not follow in https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-8 that blocks bug 1158032?

Comment 3

[Hiroyuki Ikezoe (:hiro)]

'follow' might be somewhat misleading there.  I meant our implementation is slightly different from what the Frame Timing spec is supposed.  See fig.1 in the spec<https://w3c.github.io/frame-timing/#introduction>.
In my understanding our event loop spins independently from vsync driver.  So it will be hard to implement the Frame Timing API, especially the startTime of the API.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

I did forget to reduce sValidTypeNames size...
https://treeherder.mozilla.org/#/jobs?repo=try&revision=8c8c99ccd973

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)
> 'follow' might be somewhat misleading there.  I meant our implementation is
> slightly different from what the Frame Timing spec is supposed.  See fig.1
> in the spec<https://w3c.github.io/frame-timing/#introduction>.
> In my understanding our event loop spins independently from vsync driver. 
Right.

> So it will be hard to implement the Frame Timing API, especially the
> startTime of the API.
Why is that difficult to implement. And if it is, have you filed a spec bug that FrameTiming relies on blink implementation details.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

(it wouldn't be the first time WebPerf WG's specs rely on, or at least hint something about blink's implementation details.)

Comment 7

[Hiroyuki Ikezoe (:hiro)]

Blink does not yet implement the new Frame Timing API either. https://bugs.chromium.org/p/chromium/issues/detail?id=120796#c71.  I will check the implementation later.  Thanks.

Comment 8

[Hiroyuki Ikezoe (:hiro)]

Attachment: MozReview Request: Bug 1271846 - Drop old Frame Timing interfaces. r?baku

Review commit: https://reviewboard.mozilla.org/r/52435/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/52435/

Comment 9

[Andrea Marchesini [:baku]]

Comment on attachment 8752137 [details]
MozReview Request: Bug 1271846 - Drop old Frame Timing interfaces. r?baku

https://reviewboard.mozilla.org/r/52435/#review49660

Comment 10

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/abddf7ccee3b

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Olli Pettay [:smaug] from comment #5)
> (In reply to Hiroyuki Ikezoe (:hiro) from comment #3)
> > 'follow' might be somewhat misleading there.  I meant our implementation is
> > slightly different from what the Frame Timing spec is supposed.  See fig.1
> > in the spec<https://w3c.github.io/frame-timing/#introduction>.
Note, that figure isn't normative in any way. If, say some web-platform-tests rely on that behavior, they are just wrong and we can change them.

Comment 12

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/abddf7ccee3b

Comment 13

[Jean-Yves Perrier [:teoli]]

We never documented this old version of the spec. So I just added a comment there:
https://developer.mozilla.org/en-US/Firefox/Releases/49#Others