Jump to content

Recommended Posts


1 hour ago, Ben Markson said:

That is curious. At my end Firefox ESR 52.9.0 definitely does not exhibit the problem.

tz_esr.png.faad9070afcd522f9870e65b9cfd5117.png

tz_s.png.6217aa861c07594e40e5993e1730f654.png

Does that mean I have a setting that fixes the problem?

Ben.

 

 

maybe.

similar result observed in mypal68 here:

26tSo0g.png

and SP52 (latest package):

996N6gc.png

 

Link to comment
Share on other sites

@Ben Markson & @roytam1 

Although what I'll bring up concerns a different browser engine (360EEv13, based on Chromium 86), perhaps the time discrepancy is attributed to a Windows XP quirk/bug, especially if you take into account that upstream codebases (UXP by MCP, Chromium 86) were never meant to be run under Windows XP :sneaky: ...

In the autumn of 2022, our dear @Dave-H :P complained about 01:00 discrepancies in the timestamps of the history entries of his 360EEv13 profile under XP, when the UK observes BST (UTC+01:00); this issue doesn't manifest itself when the same profile is launched under his Win10 partition; mitigation of the issue, though, under XP involved unchecking the "Automatically adjust clock for DST" control panel setting and manually selecting a region with a [UTC+01:00] timezone for the duration BST is being observed ; you can read the exchange between me and Dave by going to 

https://msfn.org/board/topic/182876-360-extreme-explorer-modified-version/?do=findComment&comment=1226930

and do read some posts after that (and the previous page, too, if you don't mind ;) ) ...

Best regards :) !

Link to comment
Share on other sites

On 4/18/2024 at 3:09 AM, j7n said:

These sites are real pigs: YouTube, HDtracks and new Discogs (contains a mandatory YouTube window).

I was just scrolling through one comments page on (new) Reddit and it made private bytes figure of palemoon.exe in System Informer go up by about a gigabyte (Win11, 32-bit Pale Moon 33.0.2), same in page file window of System Informer. Not sure I saw that gigabyte anywhere in Task Manager, at least it wasn't under any paged category.

Link to comment
Share on other sites

That's exactly why I use Proxomitron but it is "too complex" for most people to "learn", they want something like uBO where "lists" are put together for them.

Instead of teaching a man to fish and feeding him for a lifetime, web browser users just want that one fish to be fed to them one at a time, they have no interest in "learning how to fish".

For example, the very MSFN page we are on right now has FIFTY scripts.

My Proxomitron blocks 13 of them before the web browser even sees them (also why I do not need 20/30/60 uBO lists and my FIVE do just fine.

I guarantee that my FIVE uBO lists coupled with my Proxomitron config is blocking way way wwaayyy more than those 20/30/60 uBO "spoon-fed" lists.

ps - Proxomitron counts actual physical scripts, inline and fetched, unlike uMatrix or uBO which only counts fetched files.

image.png.6ed84b295cb1066aa2acf074b97a3db3.png

image.png.4ec354088a0c7ce1a2212d953a5dc6bd.png

Edited by NotHereToPlayGames
Link to comment
Share on other sites

It seems there's something about memory compression in Win10/11 that keeps some of those values down (I disabled it recently for testing). Physical memory usage didn't increase much with opening that Reddit page, maybe 100 - 200 MB.

Link to comment
Share on other sites

@roytam1

It seems that Inspect Element (Q) does not work in the New Moon v27 (the DOM content is empty, even for the simple offline pages). Tested the latest version, but the bug is probably older.

Link to comment
Share on other sites

Just to summarise. :)

Under the original Firefox ESR 52.9 new Date().toLocaleString(); always returns the correct time as shown on the system clock.

It would appear that various forks, I am currently using Serpent v52.9.0 (2024-04-19) (32-bit), sometimes return the wrong time.

· It is only wrong under Windows XP.
· It is only wrong if XP is configured to automatically apply daylight saving AND there is a DST adjustment in force (e.g. British Summer Time).
· The console's timestsamp is correct, it is only javascript that seems to return the wrong time.

Incidently, something like: new Date().getHours() + ':' + new Date().getMinutes(); always returns the system time correctly, so it seems to be specifically toLocaleString() that has the problem.

If the wrong time happened under both the original Firefox and the forks I would put it down to some Microsoft XP Api quirkiness but as the time is correct under the original Firefox this suggests that the forks have picked up some broken code – although it is perverse that it only seems to effect XP.

I did, somewhat optimistically, try swapping out api-ms-win-core-timezone-l1-1-0.dll for the original Firefox version but it made no difference.

Ben.

Link to comment
Share on other sites

2 hours ago, Ben Markson said:

Under the original Firefox ESR 52.9 new Date().toLocaleString(); always returns the correct time as shown on the system clock.

I can't confirm your observation. :no: My Windows XP system always shows the correct DST time. But I don't get the correct system time in the original Firefox ESR 52.9 when usimg the JavaScript commands:

new Date().toLocaleString();

new Date().toLocaleString('de-DE');

We have summer time here, and these commands always show the winter time (1 hour less). I only get the current, correct DST time when using this command: 

new Date().toLocaleString('de-DE', {timeZone: 'Europe/Berlin'});

Same in New Moon 28. Tested in the web console and in a clock custom button I already modified in the past. So, no need to change anything DST related in my system.

Cheers, AstroSkipper matrix.gif

Edited by AstroSkipper
Update of content
Link to comment
Share on other sites

17 hours ago, VistaLover said:

@Ben Markson & @roytam1 

Although what I'll bring up concerns a different browser engine (360EEv13, based on Chromium 86), perhaps the time discrepancy is attributed to a Windows XP quirk/bug, especially if you take into account that upstream codebases (UXP by MCP, Chromium 86) were never meant to be run under Windows XP :sneaky: ...

In the autumn of 2022, our dear @Dave-H :P complained about 01:00 discrepancies in the timestamps of the history entries of his 360EEv13 profile under XP, when the UK observes BST (UTC+01:00); this issue doesn't manifest itself when the same profile is launched under his Win10 partition; mitigation of the issue, though, under XP involved unchecking the "Automatically adjust clock for DST" control panel setting and manually selecting a region with a [UTC+01:00] timezone for the duration BST is being observed ; you can read the exchange between me and Dave by going to 

https://msfn.org/board/topic/182876-360-extreme-explorer-modified-version/?do=findComment&comment=1226930

and do read some posts after that (and the previous page, too, if you don't mind ;) ) ...

Best regards :) !

Just to clarify, I have never run 360Chrome on the Windows 10 side of my machine, I've never had any reason to!
The history problem was not just the hour's discrepancy in the times displayed, which I could have just lived with, it was the fact that history items from earlier in the current day were not displayed at all.
:)

Link to comment
Share on other sites

12 hours ago, NotHereToPlayGames said:

That's exactly why I use Proxomitron but it is "too complex" for most people to "learn", they want something like uBO where "lists" are put together for them...

My Proxomitron blocks 13 of them before the web browser even sees them (also why I do not need 20/30/60 uBO lists and my FIVE do just fine.

I guarantee that my FIVE uBO lists coupled with my Proxomitron config is blocking way way wwaayyy more than those 20/30/60 uBO "spoon-fed" lists...

Although Proxomitron is definitely a great tool (I used for some time in the past), it's more for security nerds. :P The more tools are involved in something (filtering and blocking content, elements and scripts), the more it needs to be properly configured and readjusted. I don't want to have such an additional tool for filtering in the background. :no: uBlock Origin serves all my needs. And in some profiles, I have additionally installed ematrix. That's absolutely enough for me. No need here for more, but rather less. spanachee.gif

Link to comment
Share on other sites

1 hour ago, AstroSkipper said:

I can't confirm your observation. :no:

But I think you are getting us closer to understanding what's going on...

I think the default values for .toLocaleString() are based on your various system settings:

I have English (United Kingdom) as my XP regional country...
.dft02.png.0a3cb6142900d468dbb8f67c04bd7109.png

(GMT +00:00) Dublin, Edinburgh, Lisbon, London with Automatically adjust clock for daylight savings changes as my XP Date and Time Properties...
dft01.png.c330f702dbc8ecf314d7efb6dab1126e.png

And English/United Kingdom [en-gb] as my Firefox and Serpent language setting...
dft03.png.e5ba24338166e58fb296f898db87865f.png

This should default to: new Date().toLocaleString('en-gb', {timeZone: 'Europe/London'});

And I think that's the problem... it's all about the defaults values.

 Intl.DateTimeFormat().resolvedOptions().timeZone;

...will tell you your default time zone.

For me, under original Firefox this reports: "Europe/London" which is correct.
But under Serpent it reports: "UTC" which is plain, unadjusted, time.

So now the question is, where is Serpent getting the "UTC" string from and why doesn't it get "Europe/London"?

Ben.

 

Link to comment
Share on other sites

I also observe the problem with

new Date().toLocaleString();

with the clock lagging behind by one hour in Serpent 52. XP x64, usual settings for Slovenia, so GMT +01:00 + auto adjust for DST. I do use registry hack for the OS to interpret CMOS clock as UTC time, although I guess I'm one of the few that do, from which it seems fair to assume it's likely not related.

Pale Moon on Win11 shows actual current time for my location.

Also still lagging by one hour when called like this on Serpent:

new Date().toLocaleString('sl');

New Chromium backports (Supermium and Thorium) seem to behave as expected on XP in that regard.

I haven't checked Firefox 52.9 yet.

Edited by UCyborg
Rewording
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...