VistaLover

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

That last commit, ea6e33cd0, is nowhere to be found currently in: https://github.com/roytam1/basilisk55/commits/master Was it simply forgotten to be properly committed in the GitHub repo or was it never included in the latest builds? I attempted to load https://github.com/roytam1/basilisk55/compare/c952169...ea6e33c for a more detailed changelog between latest and previous builds (needed for a bug to be reported in a future post), only to be notified by GH that: "There isn’t anything to compare."

This one DOES NOT officially support NM28, only the official Pale Moon releases are... Excerpt from install.rdf file for latest version 1.11: <!-- Pale Moon --> <em:targetApplication> <Description> <em:id>{8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}</em:id> <em:minVersion>28.14.0</em:minVersion> <em:maxVersion>31.*</em:maxVersion> </Description> Even if force-installed (you'd have to lower minVersion to 28.10.6a1), v1.11 is not guaranteed to properly work with NM28, because it now selectively applies polyfills/workarounds based on Pale Moon's platform version value : ; sadly, NM28 does not follow PM's platform version numbering (for latest NM28, it's 4.8.5) ... Any other extension that used to install and self-update in palemoon-28.10.6a1.win32-git-20220528-d849524bd-uxp-0855ba43d-xpmod but does NOT in palemoon-28.10.6a1.win32-git-20220604-d849524bd-uxp-e8b114fe4-xpmod ?

... Which add-on and from what repository? FWIW, in the latest UXP releases, there's at least one commit imported from upstream that deals with extension updates: Issue #1909 - Guard against empty update manifest URL

While being logged in, load: https://msfn.org/board/attachments/ Tick the box in the far right on the attachments you want to delete, then click the trashcan icon; beware: can't be undone! Your original posts where the deleted attachments used to be in will now have empty placeholders (in the case of images...)

Sadly, no idea - as I've posted previously, I don't own a "Smart" device, so Android/iOS aren't able to "outsmart" me ... But I'm sure an online search will get you all the info... It will: Google Extends Chrome Support for Windows 7 Users They have already: Firefox DNS-over-HTTPS (DoH)

... That still requires access to a non-XP machine for the actual patching... BTW, the author of FlashPatch recommends "Windows 7 and above", however a fully updated WinVista SP2 + .NET Framework 4.6.x should also do the job : https://github.com/darktohka/FlashPatch/issues/24#issuecomment-1063519569 https://github.com/darktohka/FlashPatch/issues/24#issuecomment-1066203448

libstagefright fix by @roytam1, committed more than two days ago, as a response to a bug report by yours truly : libstagefright: relax ctts flags checking. libstagefright fix by Moonchild ("official" UXP), committed 21 hours ago: No issue - relax ctts flag checking in media/libstagefright MCP's code is almost identical... Conclusion/Question: Is Moonchild now following "roytam1/UXP" ?

I have a portable "installation" of 360EEv11 here, so it's not associated with the ".pdf" file extension, however, when I open a new tab there and drag-n-drop a local PDF file, it does render as expected: Visit "chrome://plugins" and verify BOTH "Chromium PDF Plugin" & "Chromium PDF Viewer" are "enabled" and "Always allowed to run":

... The "desktop" app does NOT, as it's electron-based... OTOH, I'm not sure about current support status of Git-For-Windows ; I have an old version here, "2.22.0.windows.1", that works OK on Vista SP2 32-bit: CLI version also available (using mintty terminal):

https://bonkersabouttech.com/what-is-a-tor-exit-node/

Coming to a "theater near you", even on Windows, starting with Google Chrome v103 : https://support.google.com/chrome/a/answer/7679408#winDNSdef Non-Enterprise ordinary users won't have the option to "disable", unless, of course, the "community" juggles something up...

Many thanks indeed for identifying the root cause of that "small annoyance" (I'm not that often on Twitter, anyway ...), congrats for managing to fix it, after all! However, it seems I "attract" Serpent bugs "like a moth to a flame", because I just bumped on a new regression I consider far more serious than the inability to play back a specific GIFV Twitter clip: Currently, Serpent 52's native (JS-based) PDF Viewer (pdf.js) is BROKEN . STR 1. Install latest Serpent 52 32-bit build; package filename: "basilisk52-g4.8.win32-git-20220521-3219d2d-uxp-1e871780f-xpmod.7z" 2. Launch a fresh, pristine, St52 profile 3. Load "about:preferences#applications"; you should be able to verify that the default action (handler) for PDF files is "Preview in Serpent": 4. Open a new tab and try to load the remote PDF file below: https://helpx.adobe.com/pdf/coldfusion2021-support-matrix.pdf Alternatively, drag-n-drop onto that new tab a locally saved PDF file 5. Expected Behaviour: The PDF file should be rendered in St52's native PDF viewer (pdf.js); actual result: An empty tab : I do understand ; time is also precious here, but to save you some precious time, I narrowed down a regression range: Last GOOD build: "basilisk52-g4.8.win32-git-20220423-f94c0da-uxp-059e35a46-xpmod.7z": First BAD build: "basilisk52-g4.8.win32-git-20220430-3219d2d-uxp-cf4e046f9-xpmod.7z": Hopefully, this can be identified and remedied in time for Saturday's UXP "releases" ...

Many thanks! I'd have expected an auto redirection to take place to the new hostname ("thedndsanctuary.eu" -> "dndsanctuary.eu"), but it's probably just me being "grumpy" ...