1470161 - Firefox Quantum Nightly 63.0a1 yields wrong date/time when switching privacy.resistFingerprinting on then off again

Status: RESOLVED DUPLICATE of bug 1346211

(Core :: JavaScript Engine, defect, P1)

Description

[dario.berzano]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180605171542

Steps to reproduce:

Open Firefox Quantum, do some work while leaving it open, come back to Firefox without ever quitting it.


Actual results:

Whatsapp Web shows timestamps in UTC time. Same happens for another site I use for carpooling reservations (that one's pretty annoying as I end up booking for the wrong time).

A JS console returns UTC time if I do:

    (new Date()).toLocaleString()

By restarting the browser the problem is fixed, until it appears again, under undetermined circumstances. Testing it from the JS console confirms the problem is temporarily fixed.


Expected results:

See dates/times in my timezone.

Comment 1

[dario.berzano]

Additional information:

 * From here: https://bugzilla.mozilla.org/show_bug.cgi?id=1330890 I can say that I have tried turning on and off privacy.resistFingerprinting. This is off on my Firefox though.

 * Maybe some extensions could interfere with it? I have uBlock Origin and Facebook Container only.

While I was writing the ticket, it actually happened again... here is a very interesting excerpt from my JavaScript console if it can be of any help. I am quite puzzled.

---

// Note: I am currently in CEST (UTC+2)

// Initial situation: everything works
(new Date()).toLocaleString()
"21/6/2018, 16:03:35"

// Turn privacy.resistFingerprinting to true: works (uses UTC)
// (Note I have answered "yes" to an option asking me if I always want the
// English version of webpages, so displayed time locale is changed too)
(new Date()).toLocaleString()
"6/21/2018, 2:03:47 PM"

// Turn privacy.resistFingerprinting to false: does not work!
// Shows UTC+1 which is neither UTC nor my timezone!
(new Date()).toLocaleString()
"21/6/2018, 15:03:54"

Comment 2

[Gingerbread Man]

It might be useful to know if the issue is reproducible in a brand new profile with the latest Nightly.
https://support.mozilla.com/kb/profile-manager-create-and-remove-firefox-profiles
https://www.mozilla.org/firefox/nightly/all/

Comment 3

[dario.berzano]

Thanks for your feedback, so here's my result from 62.0a1 (2018-06-21, that is, today): unfortunately nothing changes. What you see below comes from the same shell kept open while toggling privacy.resistFingerprinting in about:config.

---

// Initial situation: privacy.resistFingerprinting = false: OK (shows CEST, my TZ)
new Date().toLocaleString()
"21/6/2018, 17:42:57"

// Set privacy.resistFingerprinting to true: OK (shows UTC)
new Date().toLocaleString()
"21/6/2018, 15:43:07"

// Reset privacy.resistFingerprinting to false: NOT OK (shows UTC+1???)
new Date().toLocaleString()
"21/6/2018, 16:43:14"

---

Restarting the browser fixes it.

So, while I cannot consistently reproduce my initial issue, I can consistently report that toggling privacy.resistFingerprinting results to a buggy behaviour in retrieving the current date/time from JavaScript.

Comment 4

[Tom Ritter [:tjr]]

Thanks for the report! There's definitely something screwy in RFP that we'll need to investigate.

Comment 5

[André Bargull [:anba]]

As mentioned in bug 1409973 comment 7 and bug 1409973 comment 45, ICU doesn't understand "TZ=:/etc/localtime" <https://ssl.icu-project.org/trac/ticket/13694>, which can lead to issues when toggling RFP on and off without restarting the browser.

Comment 6

[Thorin [:thorin]]

This is not just macOS (as per ticket title) or Linux, its also on Windows

FF61 (windows) + http://browserspy.dk/date.php
- start FF with RFP=false (working as expected)
   * test: Tue Jul 03 2018 23:06:17 GMT+XXXX (YOUR REAL TIME)
   * test (locale string): 7/3/2018, XX:06:17 XX
- change RFP=true, clear all data (ctrl-alt-del) and/or hard refresh test site (working as expected)
   * test: Tue Jul 03 2018 11:07:40 GMT+0000 (UTC) 
   * test (locale string): 7/3/2018, 11:07:40 AM
- change RFP=false, clear all data (ctrl-alt-del) and/or hard refresh test site
   * tests: no changes (not working as expected)

- start FF with RFP=true (working as expected)
   * test: Tue Jul 03 2018 11:02:23 GMT+0000 (UTC)
   * test (locale string): 7/3/2018, 11:02:23 AM 
- change RFP=false, clear all data (ctrl-alt-del) and/or hard refresh test site
   * test: no changes (not working as expected)

Once RFP=true it seems to need a restart if you wish to disable the TZ

Comment 7

[André Bargull [:anba]]

Maybe it's as simple as adding a call to |tzset()| (resp. |_tzset()|) to nsRFPService::UpdateRFPPref() after updating the TZ environment variable (and before calling |nsJSUtils::ResetTimeZone()|)?

Comment 8

[Gary Chen [:xeonchen]]

From the gecko side, I can see the time is displayed correctly, so that probably something wrong within the js part.


(In reply to André Bargull [:anba] from comment #7)
> Maybe it's as simple as adding a call to |tzset()| (resp. |_tzset()|) to
> nsRFPService::UpdateRFPPref() after updating the TZ environment variable
> (and before calling |nsJSUtils::ResetTimeZone()|)?

No, this doesn't work, and it's always incorrect without switch RFP mode if I set |TZ=:/etc/localtime| when Firefox launched.

I guess (In reply to André Bargull [:anba] from comment #5)
> As mentioned in bug 1409973 comment 7 and bug 1409973 comment 45, ICU
> doesn't understand "TZ=:/etc/localtime"
> <https://ssl.icu-project.org/trac/ticket/13694>, which can lead to issues
> when toggling RFP on and off without restarting the browser.

I think this is the root cause.

Comment 9

[Gary Chen [:xeonchen]]

Turning resistFingerprinting off then calling |new Date().toLocaleTimeString()|, the value in [1] shows the timezone is "Etc/GMT-1" where /etc/localtime actually a symlink to "Europe/Berlin". The DST part therefore been ignored.

[1] https://searchfox.org/mozilla-central/rev/ad36eff63e208b37bc9441b91b7cea7291d82890/js/src/builtin/intl/DateTimeFormat.cpp#659

Comment 10

[André Bargull [:anba]]

The patches in bug 1346211 and bug 1478370 should fix this issue.

Comment 11

[Gary Chen [:xeonchen]]

(In reply to André Bargull [:anba] from comment #10)
> The patches in bug 1346211 and bug 1478370 should fix this issue.

Great! Let's see if it works.

Comment 12

[Gary Chen [:xeonchen]]

I can confirm this bug is fixed.