My Browser Builds (Part 3)

[roytam1]

New build of post-deprecated Serpent/moebius for XP!
* Notice: This repo will not be built on regular schedule, and changes are experimental as usual.
** Current moebius patch level should be on par with 52.9, but some security patches can not be applied/ported due to source milestone differences between versions.

Test binary:
Win32 http://o.rthost.win/basilisk/basilisk55-win32-git-20220611-355a4b054-xpmod.7z
Win64 http://o.rthost.win/basilisk/basilisk55-win64-git-20220611-355a4b054-xpmod.7z

repo: https://github.com/roytam1/basilisk55

Repo changes:
- import from UXP: [DOM] Clip image data transfers. (9fa9622d) (59d8a6cf7)
- Revert "ported from UXP: Issue #1909 - Guard against empty update manifest URL (7b3f9fb7)" (355a4b054)

[UCyborg]

On 6/10/2022 at 2:47 AM, VistaLover said:

... Recently, I have been toying with the idea of writing simple Violentmonkey userscripts to be used in latest Serpent 52.9.0 (and, possibly, 55.0.0) that fetch online polyfills for missing, native, Web APIs; the core-js bundle of polyfills does have ones for 'RegExp Named Captured Groups', so by the below VM userscript, 

// ==UserScript==
// @name        Add 'core-js-bundle' polyfills
// @version     3.22.8
// @description Polyfills for ES3, ES5, ES6, ES7, ES2015, ES2016, ES2017, ES2018, ES2019, ES2020, ECMAScript3, ECMAScript5, ECMAScript6, ECMAScript7, ECMAScript2015
// @namespace   core-js-bundle
// @include     https://*.iheart.com/*
// @run-at      document-start
// @require     https://cdn.jsdelivr.net/npm/core-js-bundle@3.22.8/minified.min.js
// ==/UserScript==

I was able to load OP's offending "iheart" URIs in St52:

You can add additional URIs/domains that need this "treatment" via adding corresponding "// @include" lines...

This can only work in cases where the site's code only ever sets up regex objects explicitly through RegExp().

Code like...

const myRegex = /incompatible regex here/;

...won't work.

22 hours ago, NotHereToPlayGames said:

Can you explain further?  I thought that the latest Serpent 52.9 already included the polyfill coalesc (?) and chaining (?) polyfills?

Those aren't "polyfills", those are core language syntax constructs. You can't "polyfill" core language syntax constructs.

22 hours ago, NotHereToPlayGames said:

Does this userscript add coalesc (?) and chaining (?) polyfills to NM28?  To 360Chrome v11?

It manipulates/replaces RegExp object among other things. So concluding the statement above, the answer is no.

Learn C++, Windows API and their limitations on XP, fork old Chromium, backport to XP, modify the JS interpreter to understand nullish coalescing, optional-chaining operators and code your own GUI on top since you don't like the default one. That's possible with the right skills.

[NotHereToPlayGames]

The uphill battle continues  

I migrated from NM28 to 360Chrome about a year and a half or so ago - and today, I migrate back to NM28.

 

Here's what I got hit with just this morning (this web site worked last weekend!)  --

 

 

But perfect timing with NM now natively capable of polyfill  --

[rereser]

try another useragent in the loader.ini : --user-agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36"

with this however it will not pass the ddos cloudflare protection on some sites.

Edited June 11, 2022 by rereser

[NotHereToPlayGames]

Thanks!  That did the trick.

I was experimenting with NM28 and St52, javascript and e10s and other miscellaneous settings, and holy crap, I kept wanting to smack the side of the computer to dislodge whatever was slowing it down in contrast to performance I've become used to with 360Chrome.

[NotHereToPlayGames]

1 hour ago, rereser said:

the ddos cloudflare protection on some sites

I keep hoping that "amy" can code a fix into Proxomitron Reborn.  Cloudflare has become a nightmare  

[roytam1]

5 hours ago, rereser said:

with this however it will not pass the ddos cloudflare protection on some sites.

only if site owner turned on "panic mode" switch in cloudflare dashboard.

[Mathwiz]

8 hours ago, NotHereToPlayGames said:

The uphill battle continues  

I migrated from NM28 to 360Chrome about a year and a half or so ago - and today, I migrate back to NM28.

 

Here's what I got hit with just this morning (this web site worked last weekend!)  --

But perfect timing with NM now natively capable of polyfill (sic)

Couple of interesting observations: First, Apple Safari has a reasonable version number (13.4); very unusual in the modern browser world. I haven't seen a version number that low since Microsoft gave up on IE. Even MCP seems to be jumping back on the rapid browser version inflation bandwagon - after holding the line at v28 for years, they've gone up to v31 just in the last several months. Ominous. (@roytam1 is valiantly holding the line with New Moon at version 28.10, but that was "pre-inflated" by the early days of MCP keeping pace with Firefox's version numbers until they finally gave up at - guessing - 26?)

Second, 360EE v13 identifies itself as Chrome 86. Amwater.com's banner says Chrome 80 or later is required. So 360EE v13 or 13.5 should have worked - why was a UAO required? Is the banner a lie and it actually tests for Chrome 90-something now?

[VistaLover]

10 hours ago, rereser said:

Try another useragent in the loader.ini : 

--user-agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36"

With this, however, it will not pass the DDOS Cloudflare protection on some sites.

One can always use a UA modifying extension, capable of modifying the default ONLY on designated domains (in effect, setting SSUAOs - Site-Specific-UserAgent-Overrides); I use User-Agent Switcher myself; now, what if the site requiring the SSUAO is also behind CF Protection?

52 minutes ago, Mathwiz said:

Second, 360EE v13 identifies itself as Chrome 86. Amwater.com's banner says Chrome 80 or later is required. So, 360EE v13 or 13.5 should have worked - why was a UAO required? Is the banner a lie and it actually tests for Chrome 90-something now?

Actually, the banner info is not lying per se, just telling half-truths...

Inside the 360EE default UAs, there exist additional info, besides declared Chromium version, that the AW UA-sniffing script checks (and discards ) :
https://mywaterv2.amwater.com/node_modules/platform/platform.js

1. Your OS version the browser runs on
2. An end "QIHU 360EE" fragment, indicative of the browser vendor

On my Vista SP2 32-bit laptop, 360EEv13 "advertises" the default UA below:

Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36 QIHU 360EE

Trying to load "https://mywaterv2.amwater.com", I get the same "Unsupported Browser" nag @NotHereToPlayGames gets...

I get the same nag, too, when I set a SSUAO for domain "amwater.com" like below (ommiting QIHU 360EE):

Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36

But, lo and behold, with

Mozilla/5.0 (Windows NT 6.3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36

"amwater.com" no longer complains about my "set-up" and redirects to "https://amwater.okta.com/ , waiting for me to input my log-in credentials...

@Mathwiz : Chrome 80 is indeed the minimum required, as long as your WinOS is a sanctioned one (XP and Vista are, of course, ostracised like the plague    ); I have verified that

Mozilla/5.0 (Windows NT 6.3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36

(Chrome 80 on Win8.1) does work for AW purposes... Again, the same ol' FUD about XP and Vista users definitely being part of the botnet...

[VistaLover]

1 hour ago, Mathwiz said:

after holding the line at v28 for years, they've gone up to v31 just in the last several months.

Last v28 PM release (28.17.0) was on Dec 18th, 2020; first v28 PM release (28.0.0) happened on Aug 16th 2018, so yes, the v28 cycle lasted for 2 1/2 years... But v31 did not land "overnight" ; cycle v29 lasted from Feb 2nd 2021 (29.0.0) up until Apr 12th 2022 (29.4.6), ca. 14 months, not to mention the ill-fated v30 cycle, that was eventually recalled... Should that had not happened, we'd be now at version 30.x.x

2 hours ago, Mathwiz said:

is valiantly holding the line with New Moon at version 28.10,

I believe the main reason roytam1 decided to cling onto the 28.10.x version range, despite several major differences with both upstream platform+application, was to guarantee best support (in NM28) for "legacy" Firefox extensions; that support was never removed in NM28 (unlike PM) ; due to the fact official Firefox received (from Mozilla) the Australis "treatment" starting at v29.0, several "legacy" Fx extensions (installed in NM) would load different internal code, with a chance of breakage, when the browser's appVersion has been raised to 29; and that was, IMHO, the real "blocker" for NM not climbing up to v29+...

I can't say with certainty whether that initial concern remains still valid under the current state of (roytam1's) UXP tree, but, as others have pointed out recently, it does create additional hurdles when trying to install/use needed extensions that ONLY support official Pale Moon 29+ ...

[UCyborg]

On 6/8/2022 at 2:02 AM, VistaLover said:

@UCyborg, being a contributor to the upstream project, do you think you could come up with code that would implement my suggestion (clicking the "Dump platform information" button will offer to save on disk a "PlatformInfo.json" text file - current behaviour [BC] could be retained) ?

Looks for btnDumpPlatform.addEventListener in lib/main.js and make it like this:

btnDumpPlatform.addEventListener("click", () => {
    const info = {
        "PolyfillService": toJSON(gService, "is"),
        "appInfo": toJSON(Services.appinfo),
        "addonData": toJSON(gAddonData),
    };
    delete info["addonData"]["installPath"];
    const dumpInfo = JSON.stringify(info, null, '\t');
    try {
        const filePicker = Cc["@mozilla.org/filepicker;1"].createInstance(Ci.nsIFilePicker);
        filePicker.init(Services.wm.getMostRecentWindow("navigator:browser"), "Save platform information", Ci.nsIFilePicker.modeSave);
        filePicker.appendFilter("JSON file", "*.json");
        filePicker.appendFilters(Ci.nsIFilePicker.filterAll);
        filePicker.defaultString = "PlatformInfo.json";
        filePicker.defaultExtension = "json";
        if (filePicker.show() != Ci.nsIFilePicker.returnCancel) {
            const fs = Cc["@mozilla.org/network/file-output-stream;1"].createInstance(Ci.nsIFileOutputStream);
            fs.init(filePicker.file, -1, -1, 0);
            fs.write(dumpInfo, dumpInfo.length);
            fs.close();
        }
    } catch (e) {
        alert("Palefill", e.toString());
    }
    console.log(dumpInfo);
});

[VistaLover]

On 6/7/2022 at 6:13 PM, VistaLover said:

Better watch out for the revised version of that (and eventual aftermath on the Serpent browsers),
if/when it makes it to upstream UXP...

Upstream came back with a "revised" iteration of UXP issue #1909 ,now UXP issue #1913 , and committed code

https://repo.palemoon.org/MoonchildProductions/UXP/commit/ec277eacb88c659a713ef75bda6d6381ecbdbda4

that has been merged in their master branch:

https://repo.palemoon.org/MoonchildProductions/UXP/commit/a164537057a031328a3f688cbfa17738aed067b1

@roytam1 Is that "safe" for us (especially with regard to St 52.9.0+55.0.0) ?

[Mathwiz]

1 hour ago, VistaLover said:

Inside the 360EE default UAs, there exist additional info, besides declared Chromium version, that the AW UA-sniffing script checks (and discards ) :

https://mywaterv2.amwater.com/node_modules/platform/platform.js

1. Your OS version the browser runs on
2. An end "QIHU 360EE" fragment, indicative of the browser vendor

On my Vista SP2 32-bit laptop, 360EEv13 "advertises" the default UA below:

Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36 QIHU 360EE

Trying to load "https://mywaterv2.amwater.com", I get the same "Unsupported Browser" nag @NotHereToPlayGames gets...

I get the same nag, too, when I set a SSUAO for domain "amwater.com" like below (ommiting QIHU 360EE):

Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36

But, lo and behold, with

Mozilla/5.0 (Windows NT 6.3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36

"amwater.com" no longer complains about my "set-up" and redirects to "https://amwater.okta.com/ , waiting for me to input my log-in credentials...

@Mathwiz : Chrome 80 is indeed the minimum required, as long as your WinOS is a sanctioned one (XP and Vista are, of course, ostracised like the plague    ); I have verified that

Mozilla/5.0 (Windows NT 6.3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36

(Chrome 80 on Win8.1) does work for AW purposes... Again, the same ol' FUD about XP and Vista users definitely being part of the botnet...

As Paul Harvey might have said, "the rest of the story." You'd think Amwater's banner would at least tell you that Win XP or Vista was no longer supported, rather than telling you to "update" your browser to a version older than the one you're running! But they probably don't care, as long as those "evil" XPers are kept out of their site.

But that leaves me wondering: Why is NM 28 allowed, even though its default UA would reveal the same evil Windows version? I guess some mysteries will never be solved.

40 minutes ago, VistaLover said:

Last v28 PM release (28.17.0) was on Dec 18th, 2020; first v28 PM release (28.0.0) happened on Aug 16th 2018, so yes, the v28 cycle lasted for 2 1/2 years... But v31 did not land "overnight" ; cycle v29 lasted from Feb 2nd 2021 (29.0.0) up until Apr 12th 2022 (29.4.6), ca. 14 months, not to mention the ill-fated v30 cycle, that was eventually recalled... Should that had not happened, we'd be now at version 30.x.x

So PM 30 was sort of their Windows 8! "Whoops, this was a hot mess; better clean things up with a new version ASAP."

PM 29's life cycle seemed short, but perhaps that's because I was "spoiled" by PM 28's long life cycle, and/or because PM 29's subversion numbers only got up to 4, making it seem shorter. The Covid pandemic may have warped my perception of time as well.

42 minutes ago, VistaLover said:

I believe the main reason roytam1 decided to cling onto the 28.10.x version range, despite several major differences with both upstream platform+application, was to guarantee best support (in NM28) for "legacy" Firefox extensions; that support was never removed in NM28 (unlike PM) ; due to the fact official Firefox received (from Mozilla) the Australis "treatment" starting at v29.0, several "legacy" Fx extensions (installed in NM) would load different internal code, with a chance of breakage, when the browser's appVersion has been raised to 29; and that was, IMHO, the real "blocker" for NM not climbing up to v29+...

I can't say with certainty whether that initial concern remains still valid under the current state of (roytam1's) UXP tree, but, as others have pointed out recently, it does create additional hurdles when trying to install/use needed extensions that ONLY support official Pale Moon 29+ ...

I might have compromised and increased NM's subversion number to 17 from 10 by now, maximizing compatibility with PM add-ons while avoiding the pitfalls with legacy FF ones. But it's not my project, and I'm sure Roytam1 has other reasons to stick to 28.10. NM isn't even my main browser, so my interest is mostly academic anyway.

[roytam1]

1 hour ago, Mathwiz said:

I'm sure Roytam1 has other reasons to stick to 28.10

mostly because I de-railed from upstream in 28.10.

and legacy Firefox extension support is another main reason for me to stick on major version as 28.

[roytam1]

2 hours ago, VistaLover said:

Upstream came back with a "revised" iteration of UXP issue #1909 ,now UXP issue #1913 , and committed code

https://repo.palemoon.org/MoonchildProductions/UXP/commit/ec277eacb88c659a713ef75bda6d6381ecbdbda4

that has been merged in their master branch:

https://repo.palemoon.org/MoonchildProductions/UXP/commit/a164537057a031328a3f688cbfa17738aed067b1

@roytam1 Is that "safe" for us (especially with regard to St 52.9.0+55.0.0) ?

will have a look again later