1571098 - The tooltip for the number of blocked trackers in the Protection Panel shows the Since date without taking into account clearing cookies

Status: NEW

(Firefox :: Protections UI, defect, P3)

Description

[(no longer active)]

STR:

1. Use Nightly for a while.
2. Clear your cookies.
3. Open the protection panel and hover the number of blocked trackers.

Mine says: "Since July 3, 2019".

about:protections, however, says: "2 trackers blocked since August 2, 2019".

That being said, as a user I actually don't really like a date being shown here, since if I clear my browser's history, I think this makes it very clear to a bystander when that has happened which may not be what the user intends.

Comment 1

[Erica Wright [:ewright]]

The date discrepancy is because the protection panel is using toLocaleDateString while about:protections is using DATETIME($earliestDate, day: "numeric", month: "long", year: "numeric"). I noticed that DATETIME in the ftl file is always one day behind, even when the two are given identical timestamps. This is perhaps a bug in our implementation of DATETIME in fluent. However, I was also encouraged to use fluent's DATETIME because toLocaleDateString uses the web locale and not the product locale, which could be different.

Comment 2

[(no longer active)]

(In reply to Erica Wright [:ewright] from comment #1)

The date discrepancy is because the protection panel is using toLocaleDateString while about:protections is using DATETIME($earliestDate, day: "numeric", month: "long", year: "numeric").

Wow, I wouldn't have guessed that! If I am reading the code correctly, they're both computed from TrackingDBService.getEarliestRecordedDate(), is that right? I'm really puzzled as to how they can be formatting dates in a way that end up almost a month apart from each other...

I noticed that DATETIME in the ftl file is always one day behind, even when the two are given identical timestamps. This is perhaps a bug in our implementation of DATETIME in fluent. However, I was also encouraged to use fluent's DATETIME because toLocaleDateString uses the web locale and not the product locale, which could be different.

I have no idea what locale toLocaleDateString() is using here which is making it return July 3...

Should we try to use the same mechanism everywhere?

FWIW I also noticed that now after a few days and having updated my Nightly, the Protection Panel is returning August 1, 2019 whereas the Protection Report is returning August 2, 2019. There is still a day of difference between the two (that may be the issue you were alluding to above), but I believe there may still be the bug I was reporting in comment 0, that is, right after clearing history the date shown in the Protection Panel becoming stale...

Comment 3

[Erica Wright [:ewright]]

Thanks, I'll file a new bug for the off-by-one error. It's unrelated to the caching that is going on in the panel.