emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#40765: closed ([Bug-gnuzilla] JavaScript bug in Date class, incorrec


From: GNU bug Tracking System
Subject: bug#40765: closed ([Bug-gnuzilla] JavaScript bug in Date class, incorrect date/time returned)
Date: Wed, 22 Apr 2020 12:55:02 +0000

Your message dated Wed, 22 Apr 2020 22:54:48 +1000
with message-id <address@hidden>
and subject line Re: bug#40765: [Bug-gnuzilla] JavaScript bug in Date class, 
incorrect date/time returned
has caused the debbugs.gnu.org bug report #40765,
regarding [Bug-gnuzilla] JavaScript bug in Date class, incorrect date/time 
returned
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden.)


-- 
40765: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=40765
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Re: [Bug-gnuzilla] JavaScript bug in Date class, incorrect date/time returned Date: Wed, 22 Apr 2020 22:18:51 +1000 One additional note that may help others diving into this issue. I found that disabling "privacy.resistFingerprinting" immediately changed the result of `new Date().toString()` on all tabs, but `new Date().getTimezoneOffset()` was changed only on the about:config tab. After a restart all tabs showed the correct offset.

Regards,
Ben

"Wed Apr 22 2020 12:14:56 GMT+0000 (UTC)"
​
Hi Mark,

Thanks for responding.

It appears that this behavior is controlled by the privacy.resistFingerprinting option.
Setting it to false solves the problem on IceCat for the desktop,
but the problem persists on IceCatMobile (Android), regardless of the option. (Even after clearing the app's Android cache, browser cache, and restarting the app.)

However, if I understand correctly, the IceCat team no longer works on IceCatMobile.
The IceCatMobile bug tracker seems inactive, though.

Regards,
Jelle

On Thu, Jun 20, 2019 at 9:04 AM Mark H Weaver <address@hidden> wrote:

    Hi Jelle,

    Jelle Geerts <address@hidden> writes:

    > var s1 = new Date().toString();
    > var s2 = new Date().toLocaleString();
> var s3 = new Date().toLocaleString('nl', {'timeZone': 'Europe/Amsterdam'});
    >
    > The resulting strings were:
    > s1 === 'Fri Jun 07 2019 13:58:32 GMT+0000 (UTC)'
    > s2 === '6/7/2019, 1:58:32 PM'
    > s3 === '7-6-2019 15:58:32'
    >
    > s1 is not as expected (bug).
    > s2 is not as expected (bug).
    > s3 is as expected.
    >
> Expected output (taken from Firefox; Chrome has the exact same output): > s1 === 'Fri Jun 07 2019 15:58:32 GMT+0200 (Central European Summer Time)'
    > s2 === '6/7/2019, 3:58:32 PM'
    > s3 === '7-6-2019 15:58:32'

    Yes, I've known about this issue for some time.

I strongly suspect that this difference in behavior is caused by one of the privacy-protecting changes that IceCat makes to Firefox 60 ESR's
    default settings, which are listed here:

https://git.savannah.gnu.org/cgit/gnuzilla.git/tree/data/settings.js?h=v60.7.0

For example, IceCat changes the default value of "geo.enabled" to false, to disable geolocation. If you think about it, revealing the user's local timezone to web sites via _javascript_ effectively allows a coarse
    form of geolocation.

If it's important to you to reveal your local timezone to web sites, I would suggest going into "about:config" and experimenting with reverting some of these IceCat configuration changes, starting with "geo.enabled".

If you could report back with your findings, that would be helpful,
    because you're not the first person to ask about this.

          Thanks,
            Mark





--- End Message ---
--- Begin Message --- Subject: Re: bug#40765: [Bug-gnuzilla] JavaScript bug in Date class, incorrect date/time returned Date: Wed, 22 Apr 2020 22:54:48 +1000 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]