Investigate whether Animations(Player) API provides new high resolution timestamp

The Animation(Player) API got implemented (https://developer.mozilla.org/en-US/docs/Web/API/Animation) and may provide a new high resolution timestamp. If so, make sure to reduce its granularity respectively. This is behind a pref, dom.animations-api.core.enabled in Firefox 38 ESR. Thus, deferring to Firefox 45 ESR.

added TorBrowserTeam201705R component::applications/tor browser ff52-esr owner::tbb-team priority::high resolution::fixed severity::normal sponsor::4 status::closed tbb-7.0-must-alpha tbb-fingerprinting-time-highres type::task labels

Trac:
Keywords: tbb-fingerprinting-high-res deleted, tbb-fingerprinting-time-highres added

Trac:
Summary: Investigate whether Animations API provides new high resolution timestamp to Investigate whether Animations(Player) API provides new high resolution timestamp
Description: The Animations API got implemented (https://developer.mozilla.org/en-US/docs/Web/API/Animation) and may provide a new high resolution timestamp. If so, make sure to reduce its granularity respectively. This is behind a pref, dom.animations-api.core.enabled in Firefox 38 ESR. Thus, deferring to Firefox 45 ESR.

to

The Animation(Player) API got implemented (https://developer.mozilla.org/en-US/docs/Web/API/Animation) and may provide a new high resolution timestamp. If so, make sure to reduce its granularity respectively. This is behind a pref, dom.animations-api.core.enabled in Firefox 38 ESR. Thus, deferring to Firefox 45 ESR.

Still preffed off -> ff52-esr

Trac:
Reviewer: N/A to N/A
Severity: N/A to Normal
Sponsor: N/A to None

Trac:
Keywords: ff45-esr deleted, ff52-esr added

Still disabled for esr52.

Trac:
Keywords: ff52-esr deleted, ff59-esr added

Actually, Element.animate() seems to be available right now already even if the other features of the API are not implemented yet (or not available on the release channel). See: https://bugzilla.mozilla.org/show_bug.cgi?id=1245000. Moving this back on our ESR 52 radar.

Trac:
Keywords: ff59-esr deleted, ff52-esr added
Sponsor: None to Sponsor4

It is safer just to revert https://hg.mozilla.org/mozilla-central/rev/59aa5395fff1

More tickets for 7.0.

Trac:
Keywords: N/A deleted, tbb-7.0-must added

Getting more tickets on our alpha radar.

Trac:
Keywords: tbb-7.0-must deleted, tbb-7.0-must-alpha added

Moving the investigation tickets to higher priority.

Trac:
Priority: Medium to High

dom.animations-api.element-animate.enabled is the relevant preference here.

Moving more tickets on our May 2015 radar.

Trac:
Keywords: N/A deleted, TorBrowserTeam201705 added

Here's a patch for review: https://github.com/arthuredelstein/tor-browser/commit/16337

Trac:
Status: new to needs_review
Keywords: TorBrowserTeam201705 deleted, TorBrowserTeam201705R added

Does this need to get added to the in-progress Mozilla patch?

Replying to arthuredelstein:

Here's a patch for review: https://github.com/arthuredelstein/tor-browser/commit/16337

We don't want to have a ResistFingerprinting-check here? What makes that feature different from, say, the one in #10286 (moved) where you explicitly added one? Or maybe that's just because the other timestamp clamping code does not have such a check either?

Replying to tom:

Does this need to get added to the in-progress Mozilla patch?

Yes, I'll add it tomorrow.

Replying to gk:

Replying to arthuredelstein:

Here's a patch for review: https://github.com/arthuredelstein/tor-browser/commit/16337

We don't want to have a ResistFingerprinting-check here? What makes that feature different from, say, the one in #10286 (moved) where you explicitly added one? Or maybe that's just because the other timestamp clamping code does not have such a check either?

Yes, I left it out to be consistent with the other clamping code we currently have in Tor Browser. Once it gets uplifted to Mozilla, we can put it behind a pref. Jonathan has already created infrastructure for that in https://bugzilla.mozilla.org/show_bug.cgi?id=1217238

Replying to arthuredelstein:

Here's a patch for review: https://github.com/arthuredelstein/tor-browser/commit/16337

This patch looks okay. Do we also need to patch GetCurrentTimeAsDouble() inside dom/animation/AnimationTimeline.h? Kathy and I are not sure how the Animation.timeline object relates to the other timing information.

Replying to mcs:

Replying to arthuredelstein:

Here's a patch for review: https://github.com/arthuredelstein/tor-browser/commit/16337

This patch looks okay. Do we also need to patch GetCurrentTimeAsDouble() inside dom/animation/AnimationTimeline.h? Kathy and I are not sure how the Animation.timeline object relates to the other timing information.

That's a good point. Animation.timeline and document.timeline aren't exposed in TBB/ESR52 because "dom.animations-api.core.enabled" is set to false. But I looked at it again and I found there is a simpler way to implement this patch that covers the *.timeline cases as well. So here's an updated patch. (The document.timeline.currentTime test doesn't run unless the "dom.animations-api.core.enabled" pref has been set to true by default, but I don't think this is a problem for TBB.)

https://github.com/arthuredelstein/tor-browser/commit/16337+1