VistaLover

... No, they don't ; Discourse are serving a browser-feature detection script (believe it or not, this is actually the recommended way to probe a browser engine, rather than blindly block it based on its UA string) and they're looking for these features: https://arkshine.github.io/discourse-features-test/ (NB: Their announcement was recently edited to also cover "import maps" (Cr89+, Fx108+)) In a nutshell, they're dropping support for Win7/8.1 , where the last Cr and Fx supported versions are 109 and 115esr, respectively... ... Please do ; the posted custom filter blocks Discourse's browser-checking script, so your browser (FxESR-115) will be served the full-blown variant of the Discourse-based forum of interest; please be aware that while this hack currently works, it's not future proof; in, say, 6 months' time, one of the browser features they're checking for might end up in production, hence one (or more) forum function might break, to some extent ... That's the way to go , though it doesn't offer any additional clue as to why all but one of your existing logins were mysteriously removed ... Glad to know and... you're welcome ... Saluti !

First, welcome to the MSFN forums ; I take it you are using FirefoxESR-115, now on v115.27.0esr, supposedly to be EoL'ed on Win7/8.1 with the next, last, release v115.28.0esr ... Do you, by any chance, have uBlock Origin installed in your FxESR-115 profile? If yes, there's a way you can continue accessing the full version of Discourse-based forums in FxESR-115; read this post ; basically, you'd have to create below custom filter: ! Discourse-based forums ||*/browser-detect-$script,important uBO -> dashboard -> My Filters -> add above code -> Apply changes (header of tab) -> exit dashboard then delete discourse-forum cookies (for good measure) and reload the forum page... Can you please be more specific? Which version is that exactly? Help -> About r3dfox -> ? r3dfox has recently moved into a new GitHub repo, with new Releases section ... I'll assume you currently are in v140.0.4 (not the latest, BTW) ... Did you just transplant/migrate your full FxESR-115 profile to r3dfox-140 ? Although r3dfox is Firefox-based, such big jumps between major versions are prone to profile corruption ... I would advise you start from a clean redfox profile and then, progressively, tailor it to your own needs (settings, extensions, importing bookmarks from FxESR-115, etc.) ... In FxESR-115, load about:logins (Password Manager); click the 3-dot-button (top-right) and you should see a context option to "Export Passwords"; this will save ALL your login credentials to a CSV file; via a similar, but now reverse, procedure, you can import this CSV file to r3dfox and have all your passwords restored! (Take good care of that CSV file, as it contains the passwords in unencrypted, human-readable, form). Best regards ...

Hello Reino (OT, but I'm really missing your Vista-compatible FFmpeg compiles ) While your OpenSSL binaries (archive "openssl-3.5.2-win32-shared-xpmod-sse.7z") may very well be XP+ compatible , they don't work out-of-the box as CPython dependency by swapping the already existing DLLs (of openssl v3.1.0-dev) inside cmalex's CPython assemblies with them; he's been using the same (quite deprecated and now rather insecure ) v3.1.0-dev DLLs in his 3.8.13, 3.9.13, 3.10.8 and 3.11.4 CPython offerings, but the thing is the libcrypto-3.dll and libssl-3.dll inside CPython work in conjunction with two Python DLLs, files "_ssl.pyd" and (possibly) "_hashlib.pyd"; the existing .pyd files are incompatible with your own openssl DLLs ... BTW, I'm on Vista SP2 32-bit, so I'm using cmalex's Vista-compatible 3.11.4 assembly; with the original v3.1.0-dev DLLs: python Python 3.11.4 (heads/My3.11.4-dirty:1c368b1ab42, Aug 24 2025, 19:29:33) [MSC v.1900 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import ssl >>> ssl.OPENSSL_VERSION 'OpenSSL 3.1.0-dev ' >>> ^Z <redacted>\3.11.4\cmalex\Python3114-32_Vista> Overwrite them with your own v3.5.2 DLLs and... python Python 3.11.4 (heads/My3.11.4-dirty:1c368b1ab42, Aug 24 2025, 19:29:33) [MSC v.1900 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import ssl Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<redacted>\3.11.4\cmalex\Python3114-32_Vista>\Lib\ssl.py", line 100, in <module> import _ssl # if we can't import it, let the error propagate ^^^^^^^^^^^ ImportError: DLL load failed while importing _ssl: The specified procedure could not be found. >>> ssl.OPENSSL_VERSION Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'ssl' is not defined >>> ^Z <redacted>\3.11.4\cmalex\Python3114-32_Vista> I guess newer versions of "_ssl.pyd" and "_hashlib.pyd" must be provided for openssl-3.5.2 compatibility ... @nicolaasjan openssl-3.1.0-dev inside cmalex's assemblies (both 3.10.18 and 3.11.4, both XP/Vista variants) can be updated to a slightly more recent version, openssl-3.1.2, by using the OpenSSL-3.1.2 DLLs cmalex had compiled in the past for another of his projects, ProxyMII; link below: https://mega.nz/folder/68dj2YTY#As2w31IO4Smr7gy6p1ciSg/file/Pl9yzapZ Proof: python Python 3.11.4 (heads/My3.11.4-dirty:1c368b1ab42, Aug 24 2025, 19:29:33) [MSC v.1900 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import ssl >>> ssl.OPENSSL_VERSION 'OpenSSL 3.1.2 1 Aug 2023' >>> ^Z <redacted>\3.11.4\cmalex\Python3114-32_Vista> NB: When using the Vista variants of py3.10.18/3.11.4 to compile yt-dlp_x86.exe for Vista, none of the wrapper DLLs (kernelxp.dll, ntext.dll, psapi.dll) are needed; because your resultant yt-dlp.exe binaries (for Vista) still contain file "psapi.dll", redundant on Vista ; come to think of it, I don't think file "ws2_xx.dll" is needed on Vista either, but I'm not dead certain; only cmalex can vouch for that ... Many thanks and praise to both cmalex and nicolaasjan for... keeping the torch lit (i.e. yt-dlp accessible on Win<8.1) ...

... Initial post deleted; apologies, but I misunderstood ; I later realised what was asked for was the CPython (3.11.4) assembly itself used to compile the yt-dlp.exe binary linked in nicolaasjan's forum signature...

I've made the uBO-legacy custom filter even more generic, because I've come across Discourse-based forums where the browser detecting script wasn't served from within an "assets" subfolder ; so, the version I'm currently using is: ! Discourse-based forums ||*/browser-detect-$script,important The now broken userscript just told Discourse's browser-feature-detection script that "CSS aspect-ratio (Fx-89+)" IS supported in UXP-based browsers; maybe Discourse are now looking for something new entirely or, besides CSS aspect-ratio, for additional (recent) features that the userscript (and, alas, UXP) doesn't support... A very savvy person would have to dissect the new version of Discourse's script, identify what new things they search for now and author a new userscript... Discourse, in March, issued the following announcement: https://meta.discourse.org/t/dropping-ios-15-other-old-browsers-in-july-2025/358131 so it's probably one or more of the new requirements there that broke things; FWIW, relative color syntax & subgrid aren't supported in UXP, probably the same applies to import-maps ... Recent upstream forum thread about Discourse's shenanigans : https://forum.palemoon.org/viewtopic.php?f=70&t=32600 Last post there is from Aug 13th, though...

Different builds exist based on the capacities/age of the processor (CPU) on the machine the browser build is to be launched; if your CPU is archaic and doesn't support the SSE instructions set, use the -ia32 variant (sometimes referred to as "-nosse"); if your CPU is somewhat newer and does support SSE (but not SSE2), use the -sse variant; if your CPU does support SSE2 (and later), then you should use the "normal" build, whose filename ends in just "-xpmod.7z"... PS: Not relevant for XP users, but if you're on Win7+ x64 OS and want to use roytam1's NM28_x64 fork (you may have your reasons ), there's a fourth (64-bit, only) build variant that's meant for CPUs supporting AVX2 ; filename ending in "-w7plus-avx2.7z"... So, now you know ...

Slight correction: Vista+ only, for quite some time now ... https://github.com/Eclipse-Community/r3dfox

... My local AV solution, after a Custom Scan of the executable (yt-dlp.exe), found NO threats (red rectangle in Greek, haven't had time to consult VT) :

; is that py3.9-based (so will get deprecated in October ) ? Can you at least upload manually to GitHub, where it'll be more visible and with a permanent link? Thanks ... (OT: I have serious issues with my landline since Aug 19th, my tel. number isn't working at all and my ADSL+ internet access is quite fickle; my ISP don't really know what's goin' on, they said I have to give them time until Sep 3rd (!) for them to identify the true nature of the problems ... ) Sometime later today, hopefully, I'll further comment on your previous post ...

... Probably not, so let me summarise the gist of what @j7n was talking about in his recent posts: 1. The H.264 codec is probably the best choice when you're about to playback video on a system with low H/W resources (weak CPU, low-end GPU) and a legacy OS like Win7 SP1; the decoder is natively supported by the OS (not the case in XP SP3) and via implementations like WMF/MSE, an MP4 video can be played back within a compatible browser with hardware acceleration and hardware decoding (not the same things); most Win7-era graphics cards have H.264 decoding support built-in, so even when the MP4 video is being played back in a standalone media player, video decoding is performed by the GPU, not CPU... 2. Google have recently started producing their h.264 (aka avc1) youtube encodes at very low video bitrates, even for "high" resolutions, such as 720p/1080p; thus, while the h.264 YT encodes should be preferred for downloading (because they need less computer resources to be played back once downloaded), the stingy bitrate results in sub-optimal visual experiences (blurry moving images, video artifacts of various sorts, etc.). 3. OTOH, Google continue to produce their VP9 YT encodes at exceptional bitrates, especially for the FHD/UHD resolutions (>=720p); these are large files to download, to begin with, but, once downloaded, playback on low-end machines puts a heavy toll on the CPU, because VP9 is being software-decoded; I've not researched this properly, but graphics cards with integrated, native, VP9 decoding support (aka VP9 hardware decoding) only came in the later 2010s, as part of mostly Win10 machines... TL;DR: To have the best visual experience, j7n has to fetch the VP9 YT encodes, but these are detrimental to his under-resourced machine (mostly the CPU is being utilised for video playback, resulting in excess heat and energy consumption, etc.).

So did I now: https://developer.paypal.com/tools/sandbox/ so probably NOT what you're after ; if you're limited to using UXP-based browsers (on Windows XP SP3?), then am afraid they're now dead in the water with regards to PayPal; the issue needs to be escalated upstream by users of the "official" UXP browsers (Pale Moon and Basilisk, on Win7SP1+), in the hope upstream can come up with a solution, but the relevant PMForum thread hasn't seen any further activity since July 30th... OT for this thread, but you may also appeal for help to Feodor2 in MyPal's GitHub issue tracker ; if still on XP, you might try how the Supermium browser fares on PayPal these days; might prove your only recourse...

@kuja killer , follow up: Some 2 hours after my previous post, my modem-router had to be restarted (details that necessitated that are OT here), so my ISP assigned a new IP address to my internet connection; whether this is somehow relevant or a sheer coincidence, I have no idea ... Today, after reading your latest reply, I tried to re-access https://www.paypal.com/signin (as I had done yesterday) with the same NM28 copy as before; and guess what? I was hit by the same breakage you reported: I additionally have a page header instructing me to: "Please enable JS and disable any ad blocker" but JS is enabled and uBlock Origin (legacy) completely disabled; as you detailed in your post, sliding the blue button to the right (to "prove you're a human") turns it for half a second into green (with a white tick), but then the "you've been blocked" (in Greek, in my case) page appears... It is then impossible to access the proper sign-in page ... I opened Dev Console (which PayPal detected and did NOT like ) : but nothing stands out there for me... On the same machine (with the same IP address), browsers like r3dfoxESR-115.13.0 (or even the most current, r3dfox-140.0.4) will also be presented with the human verification challenge, but is then successfully passed, after which a redirection takes place to the sought-after sign-in page... So, PayPal have started requiring "a feature" (JS, CSS, both) that is to be found on relatively (more) recent Firefox incarnations, but isn't found currently in UXP browsers (and MyPal); this is based on feature detection, so a SSUAO won't work, as noted... And yes, PayPal are using their "own" captcha: https://geo.ddc.paypal.com/captcha?..... Further researching this, Google have provided an alternative sign-in page, https://www.sandbox.paypal.com/us/home => https://www.sandbox.paypal.com/signin which loads for me straight away in both NM28 and St52; as said already, I don't have valid credentials to test whether one can successfully log-in, hopefully it'll work for you (assuming that signing-in to "www.sandbox.paypal,com" logs you, too, to "www.paypal,com") ... Regards ...

I've also observed this myself; the other day I DLed a BBC-made 30min documentary off their official YT account (videoID=Pxozxj03l18) and though I initially wanted the 720p25 variant (in h264), I went, in the end, for the 1080p25 one (h264, ca. 1600kbps), because 720p25 was a measly 500kbps ... ... They're probably targeting ChromeOS laptops and/or Android-based UHD SmartTVs; little do they care for "legacy" OS/HW setups; and h264 still costs them patent fees, whereas their own VP9 codec (and av01) is royalty-free...

@kuja killer Paypal-related issues have also appeared in the upstream forum: https://forum.palemoon.org/viewtopic.php?f=61&t=32581 https://forum.palemoon.org/viewtopic.php?p=264391#p264391 Mixed reports from various users there, probably depending on their physical location; PayPal are conducting various A/B tests, it seems (read e.g. this PMForum thread ); user at the second link I posted thinks that it's NOT CloudFlare, but a PayPal-specific recaptcha (security check) that is NOT compatible with UXP-based browsers ... Can you try again with a fresh NM28 profile, where you block nothing? FWIW, with my ISP's Greek IP, I can access https://www.paypal.com/signin in NM28 at this very time without issue, but, as I don't have an account with them, can't proceed any further...

...It wasn't working for him, but now it is : PS: The forum software doesn't send a second (e-mail) notification to thread-subscribed members after one has edited one's original post (for which an initial notification has already been sent) ... Browser profile corruption is always a possibility, so, as others have noted, regular profile back-up and back-up of important info on physical copies is always strongly recommended ... ... Probably NOT ...

... Your generalised , yet unhelpful , comment about AVs aside, what I actually meant with "berserk" was that the ZIP archive (and contained yt-dlp.exe binary) shared by nicolaasjan previously here was flagged, more specifically the wrapper DLL file "libxt.dll"; I'm sure this is a false positive, yet many AV engines won't "tolerate" well such wrapper DLLs, which hook and alter system file behaviour ; on VT, half (31/67) the engines listed there ALSO flag the archive as "malicious": https://www.virustotal.com/gui/file/6ee52d1561e7ba3fc833eef35673d35b5325b2a5aad4efeeda5a1ae2c08aba41/detection ... but let's NOT turn this into an AV pros & cons discussion; MSFN has a dedicated forum/thread, oftentimes turbulent and cyber-bullied ... I whitelisted the archive and binary, what I wanted to convey was that the binary wouldn't even launch under Vista SP2, let alone perform a video download test ...

... One should visit nicolaasjan's GitHub repo ; load latest yt-dlp release, https://github.com/nicolaasjan/yt-dlp/releases/latest then expand assets (if not expanded) and there they are : yt-dlp_win7.exe => 64-bit compile, yt-dlp_x86_win7.exe => 32-bit compile, BOTH are built on py3.13, so are good for the next 4 yrs, at least... Win7-compatible py3.13 courtesy of adang1345 ... Well, you didn't go through the GitHub issue I linked to ; there are automated solutions suggested such as this one : https://github.com/grqz/yt-dlp-getpot-jsi/blob/master/README.md @user57: https://www.python.org/downloads/release/python-31018/ is the latest py3.10 release by the PSF (security-only release in source-code form: https://www.python.org/ftp/python/3.10.18/Python-3.10.18.tar.xz ) Let me just say that achieving Vista SP2 (NT 6.0) compatibility should be much easier that targeting XP (NT 5.x); the last Vista compatible version was py3.7 (py3.4 for XP SP3). One should thoroughly comb the py3.10 source code and identify ALL the Vista breaking code the PSF authored after py3.7; these changes should then be reverted or rewritten with "translated" code that is py3.7 compatible; once that task has been completed, the modded source should then be compiled with a suitable compiler (MSVC and/or MSYS2) targeting NT 6.0 and, also, the 32-bit architecture; but this is NOT all ; yt-dlp itself has quite a large number of dependencies, i.e. Python modules; the py3.10 wheels for them to be found on PyPI are made with the official py3.10 in mind, so compatibility with a Vista-py3.10 isn't always a given, especially in the case when the modules contain C/C++ extensions (i.e. DLLs, which, under Windows, have the .pyd file extension); these Python modules have to be recompiled from their sources using the modded py3.10 and the same compiler that compiled py3.10 itself (probably on a Win10 host). Things on XP should be even more difficult because several py3.10 own dependencies, e.g. OpenSSL, have moved away from XP long time ago... https://github.com/adang1345/PythonWin7/blob/master/Notes.md#python-310 and https://github.com/adang1345/PythonWin7/tree/master/patches are adang1345's instructions on how to make py3.10 run on Win7; perhaps they'd be somehow useful for someone wanting to also attain NT 6.0 compatibility ... PS: the yt-dlp devs are adamant on always dropping a Python version once the PSF have dropped security support for that version (they're also keen on using the latest bells and whistles a new Python version comes with ) ; and the PSF always align themselves behind Microsoft when it comes to the Windows OS, so, as a result, only Win10+ is officially supported now ... PS2: Maroc's py3.11 offering previously discussed is what is called a binhack (binary hack): official DLL and EXE binaries are HexEdited and XP-incompatible functions are either stubbed or forwarded to a set of wrappers, mostly One-Core-API and/or Wine DLLs; the end result 1) makes my antivirus solution go completely berserk 2) WON'T even launch under Vista SP2 32-bit, as the wrapper DLLs specifically target NT 5.x system DLLs ...

First of all, have a read of below yt-dlp GitHub issue tracker comment: https://github.com/yt-dlp/yt-dlp/issues/13965#issuecomment-3168934752 Some of the described solutions may work for you (as they did for others ) ... At the same time, the yt-dlp devs are already working towards the (plausible) scenario of SABR-only: https://github.com/coletdjnz/yt-dlp-dev/tree/feat/youtube/sabr https://github.com/yt-dlp/yt-dlp/pull/13515#issue-3164587812 (latest test release, requires Win10+: https://github.com/coletdjnz/yt-dlp-dev/releases/tag/2025.08.10.010506 ) Since you're mostly on WS2008R2, the server edition of Win7, and @nicolaasjan already provides Win7-compatible (py > 3.9) yt-dlp compiles, you should be good to go when the currently experimental SABR downloader makes it, in due course, to the release branch of yt-dlp; Vista SP2 and XP SP3 users will be the ones "left stranded on a desert island" after October, because so far no solution has materialised for those users (i.e. a CPython > 3.9 recompile/fork that would launch BOTH on NT 5.x/6.0, having additional support for all yt-dlp required Python modules ) ...

https://ssyoutube.online/privacy-policy

Well, r3dfox comes with SSUAO (site-specific-user-agent-override) support , so I bet you can set one just for chase.com and be done with (i.e., it won't affect other domains/sites) : general.useragent.override.chase.com;"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0" FWIW, "128.0" is the previous ESR version, currently at v128.13.0, which is supported for a month or two more , to be EoS'ed with v128.14.0; it's highly probable by that time that Chase's minimum requirements will get upped to "140.0" , the current ESR branch (now in v140.1.0) ...

... Is it this one ? https://repo.palemoon.org/MoonchildProductions/UXP/commit/76c9a8a09fa5eb6d0a7567adefeb57a4dbdf2964

One of the features of r3dfox I like the most is the fact it allows for the installation of UNSIGNED Firefox extensions, despite itself being derived from the "Release Branch" of upstream Mozilla Firefox; in "stable" (and "beta") Firefox, the pref "xpinstall.signatures.required" defaults to "true" but even when toggled, it doesn't produce the desired effect: UNSIGNED extensions remain incompatible and won't install (Mozilla's decision to protect the "masses" - this term is now used loosely, considering the declining Firefox userbase - from shooting themselves in the foot ) ... The way r3dfox achieves this is via two buildconfig flags (issued at build time): --with-unsigned-addon-scopes=app,system --allow-addon-sideload ; additionally, in the resulting binaries, "xpinstall.signatures.required" defaults to "false" ... As in the case of ESR Firefox/r3dfox builds, the add-ons manager (AOM, about:addons) will let you know of installed unsigned extensions, if any, by displaying a coloured "warning" bar underneath each unsigned extension (taken from 128.12.0esr): Personally, I regard these "warning" bars as (slight) irritants, polluting my AOM's view, so, starting with r3dfox-115.13.0esr onwards, I have been systematically hiding them via custom userContent.css code: /* Remove "Recommendations" from AOM, https://www.reddit.com/r/firefox/comments/184nqq0/how_to_remove_recommendations_page_in_firefox/ */ @-moz-document url-prefix(about:addons) { .category[name="discover"] { display: none !important; } .addon-card-message[type="warning"] { display: none !important; } } Above code was working flawlessly up-to-and-including r3dfox-139.0.4-2 (Greek, "el", locale shown below): Enter r3dfox-140.0.4 , to which I updated yesterday; imagine my surprise+disappointment when the AOM was loaded: Make no mistake; I did go through 140's Release Notes as hosted on GitHub, prior to installing, and, as another MSFN member noted, they stated: IMHO though, any r3dfox-specific change likely to interfere with user customisation, however small, IS worth mentioning in Release Notes... Luckily for me, I found my way to 140's source code in GitHub and immediately noticed what looked to be the culprit commit: https://github.com/Eclipse-Community/r3dfox/commit/c69c8d07e9e421ef8b3f3ea6b730f8b3a4443fa8 With respect to the browser author , changing the "aboutAddons.ftl" file, part of the embedded en-US locale, isn't a smart thing to do, unless: 1) you restrict users exclusively to the embedded en-US locale, 2) you have the resources to produce yourself (i.e. translate from English-US) the rest of the locales; e.g., once one installs the Mozilla-provided 140.0.4_en-GB locale, the author changes are being reverted to what the Mozilla wording is: FWIW, the change in the "aboutaddons.js" file is what BROKE my custom CSS code above; sanity returned when the code was amended accordingly : /* Remove "Recommendations" from AOM, https://www.reddit.com/r/firefox/comments/184nqq0/how_to_remove_recommendations_page_in_firefox/ */ @-moz-document url-prefix(about:addons) { .category[name="discover"] { display: none !important; } /* https://github.com/Eclipse-Community/r3dfox/commit/c69c8d07e9e421ef8b3f3ea6b730f8b3a4443fa8#diff-602c847d11b48c077836e06c7ee9e9e8450ad6a90d39211ba75530743c44fbb7 */ .addon-card-message[type="info"] { display: none !important; } }

https://repo.palemoon.org/MoonchildProductions/UXP/issues/2078 (CLOSED some 2 1/2 yrs ago ...)

What version of New Moon? What SSUAO in use? In what way does the site NOT work for you? I'm currently using: general.useragent.override.arte.tv;Mozilla/5.0 (Windows NT 10.0; rv:128.0) Gecko/20100101 Firefox/128.0 and a very old by now NM28 (v28.10.7a1, 32-bit, 2024-09-06) has no issues here, both loading the site AND playing back videos:

... OT , but JRE 8u461 has already been released: For the duration it's the current version, it can be downloaded anonymously from: https://www.java.com/en/download/