VistaLover

FWIW, I was able to reproduce the browser crash on a new/fresh Serpent 55 profile, with only github-wc-polyfill_v1.2.19 (force-)installed:

... On June 26th/27th, bloody Microsoft devs unleashed a set of newer-JS-syntax-containing GitHub scripts; "new" JS features included the dreaded Optional Chaining ("?.") and Nullish Coalescing ("??") operators, that can't be polyfilled (but, perhaps, could be transpiled...). Fortunately for "us", very recent UXP-based roytam1 forks (e.g., I use myself St52 and, occasionally, NM28) have these two operators natively supported, thanks to the efforts of an "upstream" dev! ; of course, you need either the github-wc-polyfill (v1.2.19) or palefill (v1.14) extension in order for GitHub to be usable in UXP-based browsers, but, all things considered, latest Serpent 52.9.0 (and, probably, latest NM 28.10.6a1) survived these most recent GitHub changes practically unscathed... Goes without saying that in browsers lacking such support (older UXP-based builds, Chromium forks based on Ch<80 - yes, these include both 360EEv11/v12 ), GitHub is basically now BROKEN (you can simply browse GitHub pages, but you can't do many "useful" things on them ...). And here comes Serpent 55.0.0 ; after the recent "sync" with UXP (thanks roytam1), and for a brief period of several weeks, GitHub was fully functional in St55, provided, of course, gh-wc-polyfill/palefill had been force-installed there (neither of these two extensions cater "officially" for the moebius fork...). AIUI, latest St55 [v55.0.0 (2022-06-22) (32-bit)] should have native support for both "?."+"??" operators, backported from UXP; however, after the recent GH changes, I find that GH is no longer usable there ; I have gh-wc-pf_v1.2.19 force-installed and many GH pages do work as expected, but other pages cause the browser to fully crash ; example is the main repo page of any GH project, e.g. https://github.com/gorhill/uBlock https://github.com/JustOff/github-wc-polyfill etc., the issue tracker of a project will also, often, produce a crash and, last-but-not-least, trying to access your GH account via your avatar (top right) will ALWAYS result in a full-blown browser crash... @roytam1 : Please, can you reproduce at your end? Given that latest St52 doesn't suffer from this, does this mean you need to transfer more UXP "stuff" to moebius for GH to work, or is that no longer possible? As I've posted in the past, GitHub is a site I use many times daily, I already lament the loss of proper support in 360EEv11/v12, I thought St55 would've been my third option besides St52+360EEv13, only to sadly find it, too, has been broken by Microsoft...

Latest Serpent 52.9.0 (2022-06-23) (32-bit) on Vista SP2 x86; saving an image file works as expected, however Error Console records: Timestamp: 27/06/2022 19:35:17 Error: Failed to load module resource://gre/modules/DownloadUIHelper.jsm. Source File: resource://gre/modules/XPCOMUtils.jsm Line: 279 Timestamp: 27/06/2022 19:35:17 Error: SyntaxError: invalid property id Source File: resource://gre/modules/DownloadUIHelper.jsm Line: 132, Column: 31 Source Code: async confirmLaunchExecutable: function (aPath) both associated with "DownloadUIHelper.jsm"; I would hate it if the reported breakage has anything to do with martok's "async"-related PR, because, thanks to it, "*.notion.*" URls work again in UXP-based browsers!

Nothing to be surprised about... Taking "msfn.org" as the example here, the site's certificate authenticity is verified via a cert chain that ends with a built-in root called "ISRG Root X1"; its validity starts June 6th 2015, so ca. 3 yrs before FxESR 52.9.1 was released: Now, the important thing here is when that root expires, which is June 4th 2035, so I'd say you're safe ... But even if built-in root certs expire, the user is still able to manually delete the expired ones and substitute them (manually) with updated ones (provided, of course, he's gotten hold of them, first )... (... Belated apologies for the OT , since this is a 360EE thread, but one thing led to another ...)

Nothing to be in awe of... Mozilla Firefox based browsers/forks come with their own TLS implementations, as well as their own Certificate Store; IE and Chromium forks rely on the OS certificate store (WinCert Store), hence the errors reported (due to well-known crypto deficiencies of WinXP SP3...); FTR, Serpent 52.9.0 (by roytam1) also has no issues with MSFN (and other CF) certs (nor do 360EEv12/13 "here" , because Vista SP2 has no problems dealing with ECC... ) ... Cheers

@Dave-H First, a big hello and hope you're doing well... How I wish I, too, were in the UK, to enjoy the Glastonbury coverage in the telly/iPlayer... Anyhow, I'm sorry I have to summon your "administrator" powers , but do you have the slightest on the fate of members' FLAGS? Since yesterday, they no longer display (to the immediate left of member's username), however their "placeholder" seems to still be there, along with the tooltip when that placeholder is hovered on:

... You could've at least mentioned type of Browser and build version ... In any case. I use Serpent 52.9.0 32-bit here, so that will be the one I'll experiment with... Not being a gamer myself, I had never visited that URL before, but upon loading your link, I can replicate the reported behaviour (i.e. a blank page) ... Disabling uBlock Origin (legacy) makes no difference; as you said, no error stands out in Web Console, but the tab stops loading at: https://s.rsg.sc/sc/js/20220603biee/build/intl-locale-polyfill.js Also, Browser Console reports more: GET https://s.rsg.sc/sc/js/20220603biee/build/intl-locale-polyfill.js.map [HTTP/2.0 404 Not Found 425ms] On an educated hunch, I felt that the page requires the "Intl.RelativeTimeFormat()" constructor, a JS feature first implemented in Firefox (Quantum) v65.0 and Google Chrome 71; more here ... No sigh of that in latest UXP, as you'd have imagined by now... I took an approach I mentioned earlier in this thread, i.e. I took it upon an on-line "polyfill" service (that provides "polyfills" for missing platform Web APIs) and composed a simple Userscript loaded in ViolentMonkey : // ==UserScript== // @name Add Intl.RelativeTimeFormat support // @version 0.0.1 // @description Polyfills 'Intl.RelativeTimeFormat()', first implemented in Chromium 71 // @namespace polyfill.app // @include https://*.rockstargames.com/* // @run-at document-start // @require https://polyfill.app/api/polyfill?minify&features=intl|locale=en~es // ==/UserScript== <!-- Polyfill Intl.RelativeTimeFormat, its dependencies & 'en, es' locale data --> That only accounts for English and Spanish locales; the English version of referenced URI now loads successfully in St52:

I never myself claimed that M.A.T. was always wrong , but what do you actually mean by that?

While it has seen little activity as of late , it wouldn't hurt, IMHO, to also post in the Programming MSFN subforum ; OTOH, posting multiple copies of the same "plea" should, in general, be avoided (Forum Rules -> Posting Guidelines -> 2.a) ... Kindest regards

... Another approach would be to first install Serpent Tester Tool: https://github.com/Nebula-Mechanica/serpent-tester-tool/releases/tag/1.0.0 and with that done, test install the PM-specific extension in St52/UXP ...

The CPython 3.7.x branch is the LAST that can launch under Vista SP2 fully updated (until Vista's EoS; that is "vanilla" Vista, i.e. no ExtKernel ). The 3.7 branch is currently under "security-fix" maintenance ONLY by the PSF (Python Software Foundation), as such they have ceased releasing themselves Windows binaries at version 3.7.9: https://www.python.org/downloads/release/python-379/ The current 3.7 source-only release is v3.7.13 https://www.python.org/downloads/release/python-3713/ A third-party (i.e. not the PSF) are providing Windows binaries for that version at: https://github.com/adang1345/PythonWindows/tree/master/3.7.13 Python 3.7.x will become EoL in ca. a year (23-07-2023) but, sadly, many Python projects are already considering dumping support for it , also due to the small number of actual Vista users... PSF have also dropped support for Win7SP1 (and Win8.0) in Python 3.9.x; with Win8.1's "demise" come next Jan 23rd, CPython will move to supporting only Win10+...

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) ?

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

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

I wrote: and by that I meant the ability to listen to the Live Audio Stream/Feed of, e.g., "Sacramento, CA. KISS 107.9" Radio Station, not the ability to Listen "Live" to Podcasts, which, by definition, are pre-recorded audio[-visual] media, aka AOD (Audio-On-Demand), and can't be "LIVE" ... If you do load "https://v1011sacramento.iheart.com" , the "Listen Live To Sacramento's Newest Station, KISS 107.9, Your Home For The Best Variety From The 90's & 2000's!" click area actually points to: "https://www.iheart.com/live/kiss-1079-9429/" On a non-US IP address, that link auto-redirects to: "https://www.iheart.com/podcast/" ... but with a sanctioned US IP address, "https://www.iheart.com/live/kiss-1079-9429/" loads a different page: ... from which, by clicking any of the PLAY buttons, you can listen to the station's LIVE AUDIO STREAM (it's actually a low quality, HE-AACv2 @48kbps encode...). Issues specific to 360EE should be better placed in the dedicated threads; but just to humour you, I have no issue whatsoever loading and playing back "iHeart" Podcast pages in my copy of 360EEv11 (build 2251, Russian portable RePack): if it matters, Windows Vista SP2 32-bit ...

The "iheart" URls referenced by @Art7220 fail to load fully in latest UXP browsers not because the platform (UXP) lacks support for Optional Chaining ("?.") and Nullish Coalescing ("??") operators, but because of lack of support for ECMAScript2018 RegExp features (e.g. "Named Captured Groups"); this is being demonstrated by the WebConsole error @UCyborg already posted, that one gets by trying to load either of https://v1011sacramento.iheart.com https://thenew1079.iheart.com in latest NM28/St52 Latest NM28 DOES NOT need extra polyfills for ("?.") and ("??"), as they are supported natively... The "core-js" project I linked to contains a bucketload of recent JS polyfills, but I have not taken the time myself to properly index exactly what (and I wish JSDelivr provided an easy way to just fetch ONLY the core-js polyfills one needs, instead of the whole core-js-bundle, but I couldn't figure it out myself ) ... NB that VM is a WE, so not supported in NM28; your UserScript Manager choice there boils down to Greasemonkey for Pale Moon, currently an abandonware ... 360EEv11 loads the "iHeart URIs" natively (which is yet another indication of how badly UXP fares in WebCompat ), so I had no need to use additional polyfills there for these... I suspect the real question is: "Can I use your userscript to "pay my water bills" in 360EEv11?" The answer is probably NOT (but you'd have to try it yourself...).

SyntaxError: invalid regexp group So, use different browser I guess... ... 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... That web design is abysmal , probably coded by a 20yr old who's never accessed the web in a non-mobile device , but, what the heck... BTW, the "Listen Live" feature is geo-fenced (US IPs, only).

I don't have an account on vk.com myself, so can't even test this... VkOpt extension: Why couldn't you give a link to it? I suppose you refer to: https://vkopt.net/download/ => VkOpt для Firefox => Yстановить для PaleMoon which affords file: https://vkopt.net/upd/vkopt_v3.0.8_(210206)_palemoon.xpi This is a "JetPack SDK" type of "legacy" extension, dating back to Feb 6th 2021; your screenshot directs "devs" to https://vk.com/dev/constant_version_updates (and possibly also to https://vk.com/dev/versions ) It is my understanding VK updated things on "their side" and thus the extension no longer functions as expected; there's a slightly newer version of the extension on their GitHub repo, "vkopt_v3.0.8_.210307._palemoon.xpi", so you should give that one a chance, too (unless it's already in use; unfortunately, I'm not a clairvoyant ...). TL;DR: Most likely, your "issue" isn't browser (NM28) related, but rather "extension" related (broken by VK); in any case, you should somehow contact the extension authors and notify them of this breakage... EDIT: Related: https://github.com/VkOpt/VkOpt/commit/883dfea0903276c36993fa955a4b206fbfa0dd00#commitcomment-64516745

According to SSL Labs, Chrome 49 / XP SP3 supports the following protocols and cipher suites: https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=49&platform=XP SP3&key=136 Protocols TLS 1.3 No TLS 1.2 Yes TLS 1.1 Yes TLS 1.0 Yes Cipher Suites (in order of preference) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Forward Secrecy 128 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) Forward Secrecy 256 OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13) Forward Secrecy 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) WEAK 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) WEAK 128 TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) WEAK 128 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK 112 I presume the above reflects XP SP3 fully updated until EoS, without any POSReady additional updates; NB that while Chrome 49 comes with its own TLS protocol support, it relies on the OS both for certificates (WinCert store) and supported cipher suites... For completeness, what additional (if any) cipher suites are added via the POSReady updates? To check, launch Ch49 (under XP SP3+POSReady) and visit https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html OTOH, the server "o.rthost.win" resolves into two IPv6 + two IPv4 addresses; e.g., "104.21.48.191" supports the following protocols and cipher suites: https://www.ssllabs.com/ssltest/analyze.html?d=o.rthost.win&s=104.21.48.191 Protocols TLS 1.3 Yes TLS 1.2 Yes TLS 1.1 Yes TLS 1.0 Yes This server supports TLS 1.0 and TLS 1.1. Grade capped to B. This site works only in browsers with SNI support. # TLS 1.3 (server has no preference) TLS_AES_128_GCM_SHA256 (0x1301) ECDH x25519 (eq. 3072 bits RSA) FS 128 TLS_AES_256_GCM_SHA384 (0x1302) ECDH x25519 (eq. 3072 bits RSA) FS 256 TLS_CHACHA20_POLY1305_SHA256 (0x1303) ECDH x25519 (eq. 3072 bits RSA) FS 256 # TLS 1.2 (suites in server-preferred order) TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ECDH x25519 (eq. 3072 bits RSA) FS 128 OLD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14) ECDH x25519 (eq. 3072 bits RSA) FS 256P TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) ECDH x25519 (eq. 3072 bits RSA) FS 256P TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ECDH x25519 (eq. 3072 bits RSA) FS 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 # TLS 1.1 (suites in server-preferred order) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 # TLS 1.0 (suites in server-preferred order) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 As you can verify on closer inspection, there exist no common cipher suites between what the browser and the server support, so the OP is absolutely right; the same is indicated by SSL Labs Server Test: Notice how the server is configured to only support cipher suites (TLS_ECDHE_ECDSA_*) with Perfect Forward Secrecy (PF), which, on the one hand, is a good thing, but it may limit the connection ability of older clients... @roytam1, do you have any control on this? If you could add (on the server) support for (even just one of) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13) which aren't deemed WEAK, Ch49/XP SP3 could connect over TLSv1.2... PS: For anyone vaguely interested, Chrome 49 / Vista SP2 (fully updated to EoS+TLSv1.2 support from WS2008SP2) can connect natively over TLSv1.2 via "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)" :

For NM28, you need to install https://addons.palemoon.org/addon/pdf-js-for-seamonkey/ For NM27, you need to install JustOff's https://github.com/JustOff/moon-pdf-viewer/releases (there was a v1.0.3 hosted in "addons.palemoon.org", but after the rift between MCP & JustOff and the removal of all of his extensions, it is currently AWOL ... EDIT: The Web Archive has salvaged it! https://web.archive.org/web/20200103222159/https://addons.palemoon.org/addon/moon-pdf-viewer/ https://web.archive.org/web/20200103222246/https://addons.palemoon.org/?component=download&id=MoonPDFViewer@Off.JustOff&version=1.0.3 )

FWIW, I'm using myself another (more recent) variant, https://greasyfork.org/en/scripts/377047-old-reddit-redirect along with // ==UserScript== // @name Old Reddit Favicon // @include https://old.reddit.com/* // @icon https://i.imgur.com/veJX9o5.png // @grant none // ==/UserScript== (function () { var link = document.querySelector('link[rel*=\'icon\']') || document.createElement('link'); link.type = 'image/x-icon'; link.rel = 'shortcut icon'; link.href = 'https://i.imgur.com/veJX9o5.png'; document.getElementsByTagName('head') [0].appendChild(link); }) (); that also resurrects the "old" Reddit favicon...

This isn't an accurate assessment by now even , because official Basilisk has become an abandonware by upstream... The last publicly released Windows binary was a 64-bit ONLY compile, with appVersion=52.9.2022.01.27 and BuildID=20220127135138 ; the platform submodule that was used to compile it was GRE (Goanna Runtime Environment, now dropped by Moonchild), not even UXP, and the GRE version back then (Jan 27th 2022) was 4.8.3. So, latest Serpent 52 is far more "rich" in Web Compatibility features compared to the last Basilisk build of more than 4 months ago (not to mention some other Serpent-specific features that make it more "valuable" in my eyes, e.g. WebEx & Container Tab support)... Thanks! If it was up to me, in https://github.com/RamonUnch/palefill/commit/a82544e I would've have also changed "Platform51Up" (two occurrences inside "main.js") to "Platform485Up", because (and call me pedantic ) : 1. UXP by Roytam is currently at v4.8.5, 2. 4.8.5 can't be >= 5.1.0 (i.e. 51Up ) I installed your fork in my St52 copy, then I explored its options (inside the Add-ons Manager); the "Dump platform information" button had me perplexed for a while ... By clicking that button, I was expecting a "Save File" prompt, to save on disk a "text-type" file (e.g. *.log, *.info, etc) with the dumped info, however none was showing up... The extension's documentation (original and fork) wasn't helpful in that respect, either... After fooling around for a bit, I discovered that the "platform information" is actually being printed, in JSON format, inside the browser's Browser Console (CTRL+SHIFT+J), which isn't self-intuitive... @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) ?

... Without any justification in the commit message, if I might add... But it's fallout from https://repo.palemoon.org/MoonchildProductions/UXP/issues/1909 specifically read: https://repo.palemoon.org/MoonchildProductions/UXP/issues/1909#issuecomment-30813 Since "we" are the first to be exposed to the "upstream" UXP master branch, no wonder I was hit (and reported) that bug on "our" side of things... Better watch out for the revised version of that (and eventual aftermath on the Serpent browsers), if/when it makes it to upstream UXP...

Both reverted in https://github.com/roytam1/basilisk55/commit/355a4b054c990e306b139ded685f146d9bf1ec23 https://github.com/roytam1/UXP/commit/8c7e1338ced4de4fb701bcbfe568faa20518a3db Much obliged!

Dearest @roytam1 In a previous post of mine, I made a point that, apparently, was not given the full attention it deserved... So, I'll re-iterate: Upstream (MCP) are currently further developing their platform (official UXP) with practically only one application in mind, i.e. official Pale Moon (the same can also be said about M.A.T. and his AuraRE platform, intended for his Borealis Navigator and Interlink applications). However, as things stand now, you also use your UXP-fork to build Serpent 52.9.0 (and several other forks, like the bin-oc+hyperbola ones), plus port UXP "patches" to Serpent 55/moebius... While NM28 may have a closer connection to the official PM codebase, both St52+St55 have distinct differences to PM, likely to become wider in the future; thus, one must be very wary/careful of official UXP patches as to eventual detrimental effect(s) on St52 and/or St55 (we've had recent examples of that, with disabled GMP (EME) plugins (CDMs) and "pdf.js" in St52... ) This very afternoon (despite the first heatwave - 37.5C/99.5F - of this summer....) I updated my St55 installation, from "basilisk55-win32-git-20220528-c952169c0-xpmod" to "basilisk55-win32-git-20220604-ea6e33cd0-xpmod" (or was that, perhaps, "basilisk55-win32-git-20220604-5600fe37e-xpmod" ? ) ; soon I discovered that the extension update feature was broken... While official PM has the "Tycho" AOM (add-ons manager), both St52+St55 have a "WebEx" type one, because they do also support Web Extensions (à propos, St55's WE support has declined to St52's levels, what with the recent Sync with UXP, but this is material for a future bug report ) ; also, in both browsers there exists the "extensions.update.background.url" pref, which can allow for setting up two different extension repos to watch out for add-on updates... In my copy of St55, I have extensions.update.url;https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=53.0&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=53.0&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% so that AMO would be monitored for updates of installed WEs, and extensions.update.background.url;https://addons.basilisk-browser.org/?component=aus&reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=52.9.2022.01.27&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=52.9.2022.01.27&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% so that ABBO would be monitored for eventual Basilisk XUL extensions updates (NB that, according to a MC statement I can't locate now in his forum, the ABBO repo may soon cease to exist...). The above "arrangement" used to work as expected until (& including) build "basilisk55-win32-git-20220528-c952169c0-xpmod"; "about:addons => Check for Updates" will produce an alert (View Available Updates) for, at least, four suggested WE updates from AMO: When moving on to "basilisk55-win32-git-20220604-ea6e33cd0-xpmod", "Check for Updates" stalls seemingly forever (being grayed-out), the AOM is in a permanent "Updating add-ons" state: The Browser Console is flooded with extension update manifest errors (for each checked extension), plus 19:22:10.249 1654446130246 addons.manager WARN Exception calling callback: ReferenceError: can't access lexical declaration `url' before initialization (resource://gre/modules/addons/XPIProvider.jsm:6686:1) JS Stack trace: UpdateChecker@XPIProvider.jsm:6686:1 < findUpdates@XPIProvider.jsm:7574:5 < doCommand/<@extensions.js:1168:15 < safeCall@AddonManager.jsm:191:5 < makeSafe/<@AddonManager.jsm:206:25 < process@Promise-backend.js:917:23 < walkerLoop@Promise-backend.js:801:7 < scheduleWalkerLoop/<@Promise-backend.js:737:11 I have verified locally that the culprit for this breakage is in fact: ported from UXP: Issue #1909 - Guard against empty update manifest URL (7b3f9fb7) "UXP: Issue #1909" shouldn't apply as-is on Serpent 52.9.0 and 55.0.0, because they have Extension Managers different to the one in official Pale Moon; so please, revert both https://github.com/roytam1/basilisk55/commit/5600fe3 (for St55) and https://github.com/roytam1/UXP/commit/7b3f9fb (for St52) Thanks for understanding, best regards