My Browser Builds (Part 5)

[NotHereToPlayGames]

1 hour ago, Ben Markson said:

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

Not likely.  It means the issue is with some time zones and not all time zones and that your time zone is working correctly.

[roytam1]

1 hour ago, Ben Markson said:

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

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

Ben.

 

 

maybe.

similar result observed in mypal68 here:

and SP52 (latest package):

 

[AstroSkipper]

2 hours ago, roytam1 said:

similar result observed in mypal68 here:

Regarding Mypal 68, all related to localisation and internationalisation has not been implemented yet. No correct local times. No time zones.  This was reported by me long time ago: https://github.com/Feodor2/Mypal68/issues/96

[VistaLover]

@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  ...

In the autumn of 2022, our dear @Dave-H  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  !

[UCyborg]

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.

[NotHereToPlayGames]

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.

Edited April 21 by NotHereToPlayGames

[UCyborg]

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.

[PPeti66x]

@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.

[Ben Markson]

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.

[AstroSkipper]

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. 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 

Edited April 22 by AstroSkipper
Update of content

[Dave-H]

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  ...

In the autumn of 2022, our dear @Dave-H  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.

[AstroSkipper]

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.  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.  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. 

[NotHereToPlayGames]

10 minutes ago, AstroSkipper said:

it's more for security nerds

I "resemble" that remark.  waka waka waka

[Ben Markson]

1 hour ago, AstroSkipper said:

I can't confirm your observation.

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...
.

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

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

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.

 

[UCyborg]

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 April 22 by UCyborg
Rewording