1437266 - Navigating back on youtube sometimes fails and restarts the current video with resistFingerprinting enabled

Status: RESOLVED WORKSFORME

(Core :: DOM: Security, defect, P3)

Description

[Kestrel]

STR:
1. Turn on privacy.resistFingerprinting & restart.
2. Go to youtube.com
3. Open a video in a new tab.
4. Click on a different video in the new tab.
5. Navigate back.

The URL changes when going back but the video does not change and instead starts playing from the beginning. This is a frequent but intermittent failure so it may be necessary to repeat steps 3-5. Refreshing the page loads the correct video corresponding with the URL.

Regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1742b1bdadd13a02df95ca690bea9cc42ff40c91&tochange=b996f14177a63f5f27d5222e8f1f86e9155e98da

Regressed by Bug 1217238.

privacy.reduceTimerPrecision = false has no effect with resistFingerprinting enabled by design.

privacy.resistFingerprinting.reduceTimerPrecision.microseconds = 1 does not make any difference.

It can be reproduced with privacy.resistfingerprinting = false by setting reduceTimerPrecision.microseconds = 1000000.

I made a build without the call to ReduceTimePrecisionAsMSecs() in Event.cpp and the problem no longer occurred with resistFingerprinting enabled.

Comment 1

[Jason Orendorff [:jorendorff]]

tjr, please take a look.

Comment 2

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Wow, thank you for the very detailed report! We are a bit backlogged on Resist Fingerprinting efforts right now unfortunately, but this is really helpful and we're hoping to work on RFP breakage soon.

One question, you said:

>reduceTimerPrecision.microseconds = 1000000

That's 1 whole second; normally resist fingerprinting operates at 100ms (or 100000 for the pref). Since you encountered this with just RF I'll presume 100ms also triggers the behavior.

Comment 3

[Kestrel]

I used one second precision as an extreme example to increase likelihood of occurrence. I can confirm it happens often at 100ms (100000) and down to 30ms although less frequently. I have not encountered it at 10ms in my testing.

Only the new youtube design is affected.

Comment 4

[Simon Mainey]

tor ticket: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/31318

Kestrel, is this still an issue with 16.67ms (FF103+, Bug 1692609)

Comment 5

[Kestrel]

Yes, I can still reproduce it on Nightly 104 with the first back navigation in a newly opened youtube tab. It is no longer intermittent for me and has been 100% reproducible for the last few years.

Comment 6

[Kestrel]

I can no longer reproduce this in latest Nightly.

Fix window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=31dfb9281c042ced6fbffac0a48afa7ba8d58c13&tochange=d9cb3649242ca8c13fc5f767c402d9fbfdc81bce

Fixed by Bug 1776678/Bug 1803976.