Closed Bug 1271846 Opened 4 years ago Closed 4 years ago

Drop old FrameTiming interface added in bug 1191178

Categories

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

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla49
Tracking Status
firefox49 --- fixed

People

(Reporter: hiro, Assigned: hiro)

Details

(Keywords: dev-doc-complete, Whiteboard: btpp-active)

Attachments

(1 file)

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
'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.
I did forget to reduce sValidTypeNames size...
https://treeherder.mozilla.org/#/jobs?repo=try&revision=8c8c99ccd973
(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.
(it wouldn't be the first time WebPerf WG's specs rely on, or at least hint something about blink's implementation details.)
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.
Whiteboard: btpp-active
Comment on attachment 8752137 [details]
MozReview Request: Bug 1271846 - Drop old Frame Timing interfaces. r?baku

https://reviewboard.mozilla.org/r/52435/#review49660
Attachment #8752137 - Flags: review?(amarchesini) → review+
(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.
https://hg.mozilla.org/mozilla-central/rev/abddf7ccee3b
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
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
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.