Hiroyuki Ikezoe (:hiro) Assignee
	Description • 8 years ago

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

	Hiroyuki Ikezoe (:hiro) Assignee
	Comment 1 • 8 years ago

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

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 2 • 8 years ago

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

	Hiroyuki Ikezoe (:hiro) Assignee
	Comment 3 • 8 years ago

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

	Hiroyuki Ikezoe (:hiro) Assignee
	Comment 4 • 8 years ago

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

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 5 • 8 years ago

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

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 6 • 8 years ago

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

	Hiroyuki Ikezoe (:hiro) Assignee
	Comment 7 • 8 years ago

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.

	Hiroyuki Ikezoe (:hiro) Assignee
	Comment 8 • 8 years ago

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

	Andrea Marchesini [:baku]
	Comment 9 • 8 years ago

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

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

	Pulsebot
	Comment 10 • 8 years ago

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

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 11 • 8 years ago

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

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 12 • 8 years ago
bugherder

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

	Jean-Yves Perrier [:teoli]
	Comment 13 • 8 years ago

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