VistaLover

Well, each Saturday's releases do come with a changelog (Release Notes): Trust me, I'm with you on that and really feel your pain ... But, you'd have to isolate the very exact reason(s) your "American Water" site refuses to work in UXP browsers and Chromium<86-derived ones... From past recollections of your previous posts on the subject, it would appear the culprit A.W. script(s) come into play once you sign-in to that site, thus, as you realise, making it very hard for anybody else without an account there to troubleshoot this further... Warmest (30 C currently, already...) greetings!

@EarlyRizer: First, welcome to these forums ... Second, I hate to be telling you this, but there's practically nothing you can do under XP to mitigate this... CTV.ca are using Digital Rights Management (DRM) now on the streams found under https://www.ctvnews.ca/ctv-national-news I don't know how savvy you are, but these are MPEG-DASH streams with Common Encryption (cenc), for successful playback in a browser you need a very recent version of a browser supporting the very recent version of the Widevine CDM, the Content Decryption Module owned and supplied by the omnipresent "villain" Google; the latest widevine version is 4.10.2449.0 ; WV is closed source (as you'd imagine), plus support for XP+Vista was dropped many years ago... Your current options now include: 1. Watch the national news on your smart phone (Android 7+) or smart TV; you may need to install CTV.ca's DRM'ed app... 2. Resort to another desktop machine with, at minimum, Windows 7 SP1 (fully updated), on which the latest Google Chrome and/or latest Mozilla Firefox can run (these two will come with a sanctioned WV version) 3. Use your existing XP x64 OS (provided you have ample RAM there) to install and deploy a VM of a Windows (or other) OS capable of running those recent browsers mentioned in #2. Both FxESR 52 as well as SlimJet 10 come with "ancient" WV versions, long ago deprecated by Google, and thus can't acquire decryption licences/keys from Widevine licence servers... To add insult to injury, FxESR 52 under XP doesn't support WV at all, because WV (on Firefox) itelf relies on Windows Media Foundation, a feature not found in XP... The "Error Code: 102630" is generated form the embedded JW HTML5 player, more below: https://developer.jwplayer.com/jwplayer/docs/jw8-player-errors-reference#empty-playlist But in my case (Vista SP2 x86 fully updated), when using FxESR 52.9.1 to try and play the vid, I am prompted to enable DRM: but even if I do, no dice again: I get a different error ; FxESR 52 only supports (Vista and higher) Widevine v1.4.8.903, a version blacklisted by WV lic servers eons ago... Do you get the broader picture? Google, with their tight grip on everything web-related, have their sure way of crushing all users of OSes/browsers they don't saction themselves... PS: You can (still) playback vids over at https://calgary.ctvnews.ca/video because these are NOT DRM'ed (yet?)...

FWIW, if you switch back to last weekend's New Moon 28, it should work, too... https://forums.mst3k.com/ , as do most of newer sites, is tailored to work best in recent Chrome (and derivatives)/Firefox ; for the techie specifics, they're using the Optional Chaining Oprerator ("?."), part of ECMAScript2020 (a Javascript standard); by a "stroke of luck", OCO was very recently implemented upstream and made its way into last WE's UXP browsers by Roytam1; these include latest Serpent 52.9.0 and latest New Moon 28.10.6a1; having still a NM28 build from "earlier this year" was/is the root of your issue with "forums.mst3k"... BTW, if you have any sort of leverage towards the admins of that site, you should ask them to look into providing better backwards compatibility with non-Chromium type browser engines, aka "legacy" browsers, like the UXP ones (official Pale Moon and forks, official Basilisk and forks), official SeaMonkey (and forks), etc.; more so, if you plan to be a paying customer of theirs but, at the same time, continue using browsers supporting your XP OS... Who knows, next week they'll start using Chrome 98+ specific web APIs, very unlikely to become supported "here" in a timely fashion, if ever... In such a case, your eventual request for help here will be futile, sadly ... If, OTOH, you're prepared to be using Google's latest spyware on M$'s latest spyware OS to watch your movies there (on mst3k), then case dismissed...

@roytam1 : Your latest screengrab above is from St52, but I believe @Mathwiz's issue is with St55 ...

This has been explained often times in the past, though I'm now plainly lazy to track down relevant MSFN posts... The gist of it is: H.264 (for video) and AAC (for audio) are patented decoders, inclusion of them into an app demands the app authors pay a handsome fee to the patent holders (currently the MPEG consortium). Google are big/wealthy enough to afford the fee and thus have included those decoders in their Google Chrome web browser; this is not the case for many of the rest of the Chromium-based browsers (e.g [Chrom]Opera, etc.) Mozilla couldn't afford including those patented decoders inside the Firefox browser core; instead, they shifted the onus on the operating system itself... Through the Windows Media Foundation (WMF) framework, Firefox can make use of the OS-provided copies of h.264/aac decoders for decoding HTLM5 video (audio) clips; Media Source Extensions, MSE, also comes into play here for the playback of fragmented (DASH/HLS) streams... The unfortunate thing for XP die-hards is that WMF is only supported on Windows Vista SP2 and onwards - in the case of Vista, a slightly less complete (to the one in Win7) implementation of WMF is installed via Platform Update Supplement (PUS), itself a Windows Update offering... And I can tell you that "native" H.264 support in Fx came long before v53.0 (but only available, as explained, in Vista SP2+, not XP)... Roytam1 browsers on WinXP: The FxESR 45 fork and the Goanna 3 (Tycho) based forks, i.e. New Moon 27+K-Meleon, have been modified to load the patented decoders from externally supplied (and manually installed in the application folder) LAV dlls (these are based on the open source FFmpeg project; XP-compatible versions of FFmpeg are used to compile those LAV dlls...). The UXP-based browsers (New Moon 28, Serpent 52 etc.) have been modified to load the patented decoders from a modded, internal, codec library called ffvpx; ffvpx is itself derived from FFmpeg, but in Firefox it normally only includes support for VPx and other non-patented decoders; the roytam1 version of this library has been patched to also include h264/aac support (via native FFmpeg decoders). Indeed, if you toggle the about:config pref media.ffvpx.enabled to false, said browsers lose h264/aac decoding capacity under XP... Serpent 55.0.0 => Same case as with Serpent 52 Feodor's new child MyPal68: I haven't been following its code development, feel free to visit the main code repository and discover how native h264/aac support under XP has been implemented; my educated guess is, again, via FFmpeg libs... FWIW, the Cisco Openh264 Video Codec plugin was provided in the context of WebRTC video-calls (it can both encode/decode the video stream), but it was limited to low video resolutions, only, and could not (to the best of my knowledge) be used as a full-fledged h264 decoder for general MP4/HTLM5 web clips (i.e. unlike the Adobe Primetime CDM's included decoder) ... NM28 is being compiled without WebRTC support (this is set from upstream, they NEVER supported WebRTC in Pale Moon), so no wonder the Cisco plugin is not installed by default there... And Serpent 52/55's WebRTC implementation is lagging very much behind the current Google-dictated specs, so much so that the majority of services requiring WebRTC today (2022) don't work in those browsers... OK, have you got a clearer picture now?

If you have a browser (i.e IE8, Chrome 49) configured to use ProxHTTPSProxyMII Rev3e, use that browser to visit https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html wait for ALL tests to complete (might take some time, YMMV) and then inspect the 1. Protocol Support 2. Protocol Features -> Protocols -> TLS 1.3 -> Yes or No ... sections of the test results...

Windows 7 (SP1), WS2008R2 (SP1) and WS2008 (SP2) are also supported: x86: https://www.catalog.update.microsoft.com/ScopedViewInline.aspx?updateid=f16201fc-37a1-4166-9060-0a37cf2e242c https://catalog.s.download.windowsupdate.com/d/msdownload/update/software/uprl/2022/04/windows-kb890830-v5.100_be43404f6d4e6b1ca11831948610a4d58e291374.exe x64: https://www.catalog.update.microsoft.com/ScopedViewInline.aspx?updateid=23a75426-87bc-4851-9c5e-65f4db341d80 https://catalog.s.download.windowsupdate.com/d/msdownload/update/software/uprl/2022/04/windows-kb890830-x64-v5.100_39ac11b44ee409bd2e92ab441f958815f9241ae1.exe As it's already widely known, Vista SP2 (both x86+x64) is NOT supported!

Well, things look gloomy, indeed... I've read the following CF support article: https://support.cloudflare.com/hc/en-us/articles/200170136#browser-support and they plainly state: The "non-interactive JS challenge" GitLab are sending, as part of their CloudFlare protection, is meant to work on only the major villains, i.e. Chrome and "buddies" ... That article was last modified a month ago, possibly the same time GL log-in became broken... And it would seem that User-Agent-Sniffin' does play a role, in the initial detection at least, according to: https://support.cloudflare.com/hc/en-us/articles/204191238-What-are-the-types-of-Threats-#bad-browser https://support.cloudflare.com/hc/en-us/articles/200170086-What-does-the-Browser-Integrity-Check-do- https://support.cloudflare.com/hc/en-us/articles/204191238-What-are-the-types-of-Threats-#browser-challenge Indeed, when I spoofed Serpent 52 (via an extension) in my copy of 360EEv12, it too became unable to display the GL sign-in page ; back to its default UA and the GL sign-in page becomes accessible again (as told already in my previous post) ! Conversely, when I spoof "Firefox 100.0" in Serpent 52, I'm probably being served a JS challenge that can only be solved/passed by Fx 100.0 (or whereabouts), poor old St52 simply goes belly up...

Dearest @XPerceniol ; my own stance is for people to stop meddling with "about:config" advanced settings, especially when not sure what they're about; there's a good reason why "general.warnOnAboutConfig" is by default set at "true" ; but this is just me getting grumpier as I grow older... The referenced pref is an old remnant from an era when yt were still using both Flash and HTML5 embedded players; more at this link ; for many years now, yt are exclusively using their HTML5 player, so the setting of that pref is currently moot: you'll always be served the HTML5 version of the embedded yt video... I briefly toggled the pref to false, just to humour you, no yt breakage encountered here... As for performance slowdowns, am afraid this is something you'll have to check on your own particular setup (H/W+S/W) ... Best greetings EDIT: @UCyborg beat me to it by mere seconds!

This has now been merged into the master branch of upstream-UXP: https://repo.palemoon.org/MoonchildProductions/UXP/commit/92b3def6a88f9ea15c9e51e22a57b667edea29c0 Hopefully, it will also arrive in this weekend's roytam1 builds (fingers-crossed it doesn't break other aspects of the browser ) ...

Add https://www.cloudflare.com to the long list of sites that end up loading a blank page (latest St52 32-bit); CF homepage produces several TypeErrors in the Web Console... But seriously, today I jumped into a real deal breaker for UXP-based browsers: GitLab; it is no longer possible to sign into an existing GitLab account on a UXP-based browser (plus some others, read below) ... To begin with, to even successfully load GL pages in a UXP browser you're in need of the gh-wc-polyfill extension (manually/forcibly) installed (GL break things ever so often , make sure you're on the latest beta/stable release - currently v1.2.19). As long as you're not logged-in, things appear OK... STR: 1. Load, as a guest, e.g., https://gitlab.com/cleanflash/installer/-/releases (happens to be one of my bookmarks ) 2. Click on the "Sign in / Register" button (far right, top header); GL will load https://gitlab.com/users/sign_in/ 3. This is the crucial step where things broke ; to verify you're not an automated bot trying to sign-in, GL are serving your client (browser) with a CloudFlare-based "challenge" that it has to pass successfully in order for the sign-in page to display: During the last week(s), that "challenge" has been "upped" and is no longer compatible with UXP browsers ; the browser goes into an infinite loop of those "5 seconds" redirection cycles, "frying" your CPU in the process , and never affords the GL sign-in page below: FxESR 52.9.0 and (latest) Serpent 55 behave similarly (to St52) on my Vista SP2 32-bit machine; but I also gained access to a Win7 SP1 64-bit laptop and can report that Fx 56/ FxESR 60.9.0 / FxESR 68.12.0 are also unable to generate the GL sign-in page there; however, and that's really no surprise, the latest Fx 100.0 (32-bit) passes the GL challenge with flying colors and displays the GL sign-in page in ca. 2 sec ... The "challenge" is probably "feature"-based, rather than "UA"-based, because I tried to spoof "working" Fx/Chrome versions in Serpent 52, sadly with no success ... Back to the Vista machine, I also tried 360EEv11/12; the former (v11, Chromium 69 based), does require 1 to 3 redirection cycles (ca. 5-15sec, YMMV), but eventually does pass the GL challenge and the sign-in page is shown ; the latter (v12, Chromium 78 based) passes the "challenge" more effortlessly and affords the GL log-in page very quickly (the screenshot above is with that browser) ; I then used my GitHub account credentials to successfully access my GL account in 360EEv12 (I did not bother checking v13, I'm certain it will, too, work OK ). Just as a POC, I then exported (via an extension) ALL GitLab cookies from 360EEv12 to a "cookies.txt" file (Netscape format) and subsequently imported them (via another "legacy" extension) into latest Serpent 52; and that is the only way (obviously impractical ) I could browse GL being logged-in with St52: If anyone knows of a way to make GL log-in work natively in latest St52, do come forth!

Many thanks indeed for taking the time to apply "git-bisect" in order to pinpoint the exact culprit... Thank you, too! So, the "bug" is really there in latest UXP, just masked behind the disabled (by default) serviceworkers pref... I can indeed confirm that latest St55 (2022-04-29) (32-bit) does not exhibit the reported bug once "dom.serviceWorkers.enabled" is set to false ! Now, the real question is: Is that still a genuine UXP bug or just a misconfiguration on "msfn.org"'s side? FWIW, I have sessionrestore enabled in all three flavours of 360EE (v11/12/13) and there all "msfn.org" tabs are session-restored successfully (I believe ServiceWorkers are enabled by default in Chromium browsers) ...

... These should be the other way round...

According to this , USD183.00 need to be donated for a duration of one month (Apr 10th - May 10th) for the site to stay online; this sum has been covered more than twofold already , so I'd say we're good to go for at least mid-June 2022 ; BTW, I provided that link for any future reference, as (obviously) MSFN donations is OT for this thread ...

... Here's another example of using that extension, posted by its author : https://github.com/JustOff/github-wc-polyfill/issues/28#issuecomment-920212661 ... that was meant to mitigate non-compatible (with UXP) RegExp syntax served by GitLab; it most probably can't handle "tougher nuts" like ECMAScript2020+ syntax (new operators, etc.), but I still want to suggest it as an inclusion to the "arsenal" in the fight against "latest and greatest (Chrome-only) JS features" - provided one has the know-how to compile the required "filters"...

Nullish Coalescing Operator (??) is only half of the issue here ; that same linked JS script also contains the Optional Chaining Operator (?.), first implemented in Chromium 80 and Firefox 74 (i.e. unsupported in UXP-based browsers); if you do a search for "?.", you'll, sadly, find 210 (!) hits... As I've already posted in this thread, "operators" can't be (easily) polyfill-ed (and then used in extensions like chromefill/palefill), only "methods" can; for "operators", tranpilers (JS translators) must be used, like the already mentioned babel; problem (well, one of the chain of problems) is babel is designed for server-side use (website), not client-side use (end-user's old-engine browser); thus the necessity to deploy a local server (like Proxomitron) to serve the transpiled script to the browser... @UCyborg ; I don't "speak" JS/regexp myself, but have you taken a look at https://github.com/JustOff/modify-http-response ? Could this be used to "Search & Replace" an online incompatible JS script (like the linked "*.index-docs.js") with a babel-processed local version of that script? (NB: Extension only compatible with Fx-legacy/UXP-based browsers)

Specifically, no less than 22 occurrences of the Nullish Coalescing Operator (??) inside https://conversejs.org/dist/converse.min.js The above ECMAScript2020 syntax was first implemented in Chromium 80 and Firefox 72; backwards compatibility is not a thing most 2022 webmasters are concerned with... If on WinXP, am afraid only 360EEv13 (Ch86-based) and, perhaps, miniKafan (Ch87-based) are your options for "conversejs.org" ...

You can do this via the native GUI, but several cookie-related extensions also come with that function built in... One I can recommend is EditThisCookie: https://chrome.google.com/webstore/detail/editthiscookie/fngmhnnpilhplaeedifhccceomclgfbg but my most preferred cookie manager is MILK: https://chrome.google.com/webstore/detail/milk-—-cookie-manager/haipckejfdppjfblgondaakgckohcihp These extensions offer a very fine way of managing cookies (editing/protecting/etc.) besides just deleting cookies for a specific domain... Later addition: Clicking the MILK icon when on an "msfn.org" tab, the relevant cookies are auto-displayed and then you are presented with several choices of managing them, first one being deletion: If you don't want to use an extension: Load "chrome://settings/cookies" In the search field (top right) type "msfn"; the cookies set by the domain should appear as small rectangles; you can delete them all (Remove all button) or individually:

Yes, it's most probably a platform (forked UXP) rather than an application (St52/NM28/etc.) bug... Is that Pale Moon 29.4.5.1 ? Are you certain? FWIW, in my tests (St52), the bug is present regardless of the gh-wc-pf add-on... A workaround I have found is to reload the GitHub issue tab prior to the second right-click, but it's still an inconvenience...

@roytam1 : I just, accidentally, stumbled upon yet another UXP (longstanding) bug, that manifests itself on GitHub issues; the bug is there regardless of whether the relevant github-wc-polyfill extension is installed or not... I used recent Serpent 52.9.0/UXP builds to test. STR: 1. Load a new, fresh, Serpent 52.9.0 profile (default prefs, no add-ons) 2. New Tab => Paste & Go: https://github.com/JustOff/github-wc-polyfill/issues/45#issuecomment-1066105393 NB: It is imperative the body of the issue comment contain at least one active link (not only in the form of a plain "https://*" string, but any type of "linkified" string) 3. Place the cursor on top of the active link, then right click to access the browser's context menu; so far, so good: 4. Move the cursor away from the context menu, left-click to make the menu go away... 5. Repeat step 3; right-clicking this second time results in the whole content of the issue comment to get selected: I have successfully reproduced this bug with many GitHub issue-comments, with/without the gh-wc-pf add-on... Trying to find a regression range for this bug, I've spent considerable time and effort which, in the end, got me all the way back to mid-2020: Last Good build (without the bug): basilisk52-g4.6.win32-git-20200530-d6ba7ac-uxp-1cecef624-xpmod First Bad build (with the bug as described above): basilisk52-g4.6.win32-git-20200606-547d236-uxp-fdb918dea-xpmod Hopefully, the cause could be narrowed down... Obviously, this isn't a deal breaker, however little annoyances like this one make me use more often either 360EEv11/v12 for GitHub (with extra polyfills applied there via @InterLinked 's extension), while I'd be happy to cling on to Serpent 52 for most of my on-line tasks... Many thanks

Sorry for posting this here , but since several roytam1 offerings were also previously appearing on the "eclipse" forums , do any of you know what happened to "https://board.eclipse.cx/" and where, per chance, they have moved on to? Google cache has archived a snapshot taken on Apr 2nd, but currently all that is returned on the domain is an "Account Suspended" error message...

Recent Serpent 55 builds come with a BUG involving session restore on some sites such as "msfn.org"; my tests were carried out on the latest 32-bit binary, Serpent 55.0.0 (2022.04.01) (32-bit) (BuildID=20220401234639), but I believe previous build was also affected... STR: 1. Load a fresh, new, St55 profile (default prefs, no add-ons); "about:home" should be the (default) one open tab... 2. New Tab => about:preferences => General => "When Serpent (55) starts: Show your windows and tabs from last time" 3. New Tab => Paste & Go: "https://msfn.org/board/topic/180462-my-browser-builds-part-2/page/44/" ; wait for that URL to fully load 4. Change focus to another tab, e.g. the first one (about:home) 5. Exit the browser 6. Relaunch the browser; session restore should kick in, with 3 tabs present in the tab bar, focus on the first (L to R) one (about:home) 7. Select the 3rd tab (https://msfn.org/*); instead of the content loaded during the previous session (or an attempt to reload the tab), the browser displays the following error: ... which isn't the expected behaviour... FWIW, clicking the "Try Again" blue button does end in the "msfn.org" page fully loaded, but the "bug" repeats itself the next time the session is restored; remember, for the bug to be replicated, the "msfn.org" domain tab has to be out of focus when the browser is exited! basilisk55-win32-git-20220226-01d12e322-xpmod is the last good build that doesn't exhibit the bug, basilisk55-win32-git-20220326-216281f40-xpmod is the first bad build with the bug; so I believe it's either something inside the first batch of the UXP stuff ported over to moebius or something inside the NSS Mozilla stuff... Your attention to this reported bug will be highly appreciated @roytam1 , best regards! PS: Serpent 52.9.0 doesn't suffer from this (but I'm still on the 2022-03-25 build...).

... You can always opt to clear just the cache, but retain the cookies... The main reason I suggested wiping cookies is that you yourself stated that "the problem sites load OK in a private window"; private windows, as you might know already, don't take existing cookies into account, new, "private", cookies are temporarily stored for that window and then auto-cleared when the window is exited... Are all the sites refusing to fully load ones you were already logged-in? If not, try a "problem site" which doesn't require you to have an existing account, selectively clear the cookies for that site and try to reload; if successfully loaded, then your predicament is definitely cookies-related... I don't own a mobile device myself (yes, you read that right ), so 2FA is a no-go for me; I personally think of it as yet another Google/Apple ploy to buy one of their mobile devices; I haven't enabled 2FA on any account that demands it, I just use very strong passwords (> 20 characters long), which I change very often (at least once every 3 months, and that includes my e-mail password); no on-line account of mine has been hacked yet (fingers crossed)... My two banks aren't happy, to say the least, but I still manage for the time being; on-line purchases/payments are limited to where absolutely necessary, pre-paid cards used most of the time... And, of course, I'm no member of any of the youth-oriented, very popular, social media sites/portals, these are the ones mostly requiring a "smart" phone and 2FA; one notable exception is Discord - I had to join a private server there and Discord are constantly nagging me about 2FA and installing their mobile app on my "phone" (little do they know me...) ; but I'm obviously going off-track... FWIW, accidents do happen, you should be always able to re-log, 2FA or not, to any of the sites you have created accounts for... Like my friend @NotHereToPlayGames, I'll also advise strongly against tab-hoarding! This isn't the reason tabbed-browsing was created for, I never find myself having more that 20-25 opened tabs during a browsing session... An increased number of tabs slows down things considerably, especially in the case of UXP browsers like Serpent, which have been engineered/optimised by "upstream" as single-process applications... You can create a bookmarks folder with all currently opened tabs, then each and everyone is just two clicks away - and bookmarks usually survive a browser-crash, not always the case with browser sessions ... In any case, you can back-up your current dirty profile, as suggested, so you'll have a working copy of it to fallback to... Session (includes opened tabs) info is stored in profile "sessionstore-backups" directory and "sessionstore.js" file... Assuming you have opted for When Serpent starts: Show my windows and tabs from last time you should be good recovering your session; and sessions can and will become corrupted over time, especially with a large numbers of tabs, you have been warned! Cookies OTOH are stored in the "cookies.sqlite" profile file; account credentials in "logins.json" (in conjunction with key3.db file). In fact, I'm never in any "rush" to update to the latest release of St52 (or any other app, for that matter) as soon as it's being released on a Saturday... I usually wait until the middle of the coming week, to see if any "issues" with it have presented themselves here in the forum, then I do update, having first created a backup of my dirty profile, just for good measure... As you say, I can't test the 64-bit binary here, but the 32-bit one [Serpent 52.9.0 (2022-03-25) (32-bit)] has been running for the last four hours without any noticeable hiccups ; my browsing session was successfully restored after the upgrade from the previous (2022-02-25) St52 build, I remained logged-in to both of my GitHub and MSFN accounts; ImgUr (not logged-in user) gave me some slight issues during uploading the images in this post, perhaps it was something on their end - we'll see; in any case, I have no URL refusing to fully load here! Some NSS library changes were included in these latest builds (as posted previously elsewhere in this thread), perhaps they affect the way (some) cookies are encrypted/stored/decrypted in your setup... Unless some other member here comes forth with issues similar to yours, affecting latest St52-x64, we'll assume, for now, that the issue is limited to your end; you'll have to provide additional, detailed, info about your profile, such as extensions used, etc. You've been given ample guidance on how to tackle this, as an additional test log-out from just one of the problematic sites (clearing its cookies), then try to log back in and see how that goes... Sometimes, instead of spending too much valuable time troubleshooting things at length, it's best to just dive-in and start fresh (... the "moto" at my local computer-repair shop : a re-format and OS re-install is what they always come up with for anything I seek remedy for; fortunately, on-line communities such as this one exist... ). Best regards

1,885 changed files with 168,699 additions and 191,064 deletions. Was that just to make things extremely painful for fork-maintainers ... And it turns out I was 100% correct in my suspicions... Moonchild himself admitted this, in the latest installment of the PM "drama" (i.e. after M.A.T's exit): https://forum.palemoon.org/viewtopic.php?f=62&t=28090 TL;DR: "GRE" has been now dropped, official Pale Moon v29.4.5.1 has been released, there'll will be no more v30.x.x/GRE releases, v31.0.0/UXP will be released "in the fullness of time"... What a fine mess...

... He already said that he did and the previous 64-bit St52 build works OK: Have you tried clearing up both browser cache and cookies and then restart the browser (in normal, non-private, window) ? If clearing cookies, you'll have to log-in again to the sites you were previously logged-in... Also, and this is essential, have you tried to replicate your issue with a new/fresh St52 profile? Are those FxESR 52.9.x and Chrome 49/50 (yes, Chrome 50, if you can still find it, works fine on Vista SP2) ? For the sites not supported in UXP browsers (like Serpent 52/New Moon 28), you can check versions 12 and/or 13 of the Chinese-made 360 Extreme Explorer (Chromium 78/86 forks); you can search for them in other MSFN threads, where you'll hopefully find that two competent fellow MSFN members have created and shared modded versions, with practically most of the Chinese "spyware" removed (however, these mods are primarily targeting WinXP usage...). Welcome to the forums, fellow Vista user !