VistaLover

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/

... And now yt-dlp have updated their random UA string to report Chrome 132-138: https://github.com/yt-dlp/yt-dlp/commit/c59ad2b066bbccd3cc4eed580842f961bce7dd4a#diff-b6d91e8afdfc47fb2b59e37d22d3621b79d252bc5a8205edc2b80530dcceecc2

I took a closer look at updated file "update.py": https://github.com/nicolaasjan/youtube-dl/blob/embedthumbnail/youtube_dl/update.py which you originally copied from: https://github.com/ytdl-org/ytdl-nightly/blob/master/youtube_dl/update.py The update process correctly "calculates" the hashsum of "current" version, Latest version: 2025.07.12.1, Current version: 2025.07.12 Current Build Hash 58815fc0de70a06e76a9e9ca0337dfcdda59b1db0ffed12d150df626d8cd7735 which is indeed identical to the value displayed at https://github.com/nicolaasjan/youtube-dl/releases/tag/2025.07.12 Which part of the code inside "update.py" is responsible for that? I understand that your tags/releases don't have a SHA2-256SUMSfile as asset... Updating to version 2025.07.12.1 ... WARNING: no hash information found for the release According to https://github.com/nicolaasjan/youtube-dl/releases/tag/2025.07.12.1 the missing hashsum value for youtube-dl.exe should be: 21534c1543d62f4543efff017da1c8dd18a47e64995fd7e8c84215a433752db5 Why isn't "update.py" able to "calculate" it and, more importantly, how can it be fixed? GitHub adding a "sha256:*" column under assets (not as separate asset) is a relatively new feature, AFAIAA... In file update.py, I can identify two hashsum calculating blocks: https://github.com/nicolaasjan/youtube-dl/blob/da27e0bb378940575d4ac1a5d2a9c9899f7f94ec/youtube_dl/update.py#L84-L91 Is this one for "current" (non-updated) binary? Then, there is: https://github.com/nicolaasjan/youtube-dl/blob/da27e0bb378940575d4ac1a5d2a9c9899f7f94ec/youtube_dl/update.py#L130-L138 which obviously pertains to the "updated" binary; I can see mentions there of files "SHA2-256SUMS" that your fork lacks; lastly, the WARNING is issued as a result of lines: https://github.com/nicolaasjan/youtube-dl/blob/da27e0bb378940575d4ac1a5d2a9c9899f7f94ec/youtube_dl/update.py#L172-L174 Someone knowledgeable in Python needs to review the "update.py" file and come up with a "fix"; perhaps if you kindly ask dirkf in GitHub, he could oblige ... C'mon, you know me better than that ... Sorry for being a PITA, best wishes !

... Some fine tuning is still needed, am afraid ; yes, I got build "2025.07.12" to update to "2025.07.12.1" via "-U" from the cmdline, youtube-dl -vU => [debug] System config: [] [debug] User config: [] [debug] Custom config: [] [debug] Command-line args: ['-vU'] [debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253 [debug] youtube-dl version 2025.07.12 [debug] Lazy loading extractors enabled [debug] Single file build [debug] Python 3.4.4 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2d 9 Jul 2015 [debug] exe versions: none [debug] Proxy map: {} Latest version: 2025.07.12.1, Current version: 2025.07.12 Current Build Hash 58815fc0de70a06e76a9e9ca0337dfcdda59b1db0ffed12d150df626d8cd7735 Updating to version 2025.07.12.1 ... WARNING: no hash information found for the release Updated youtube-dl to version 2025.07.12.1 but a WARNING is issued during that process: Is this something that can be fixed somehow? FWIW, that warning isn't there when updating dirkf's "nightly": youtube-dl -vU => [debug] System config: [] [debug] User config: [] [debug] Custom config: [] [debug] Command-line args: ['-vU'] [debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253 [debug] youtube-dl version 2025.02.28 [673277e51] (single file build) [debug] ** This version was built from the latest master code at https://github.com/ytdl-org/youtube-dl. [debug] ** For support, visit the main site. [debug] Python 3.4.4 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2d 9 Jul 2015 [debug] exe versions: none [debug] Proxy map: {} Latest version: 2025.05.05, Current version: 2025.02.28 Current Build Hash a1ab42ffb8175b7d32c87e986b5d9f476b952b239aae7a228fac4b6bd8a81b3e Updating to version 2025.05.05 ... Updated youtube-dl to version 2025.05.05 Thanks in advance ...

... Huh, I see ... This is very puzzling, indeed ; in fact, the "yt-dl.org" domain now auto-redirects to yt-dlp GitHub URLs, e.g. https://yt-dl.org => https://github.com/yt-dlp/yt-dlp , which, of course, is a fork of the original youtube-dl project; I think dirkf doesn't have immediate access to the "yt-dl.org" server (wasn't that one blocked in Germany at some point?), so the answer about who arranged the autoredirection to yt-dlp might be possibly found inside the yt-dlp repo itself (too hot here currently for me to check, sorry ) ... I know; however, I have a small list of test commands I issue with fresh releases of both youtube-dl (nightly branch) and yt-dlp (your "Vista" compatible build) and that same list was used to test your 2025.07.11 compile; that was how I noticed the change in behaviour for " -vU" ... As I'm not proficient in Python (quite the opposite, in fact ), that was what I was about to suggest to you ; glad you got it sorted already ... The same with most "yt-dl.org" links contained inside: https://ytdl-org.github.io/youtube-dl/download.html I know ; I had already modified locally the latest "official" Nightly release (2025.05.05) according to your posted diff on GH; let's hope a py3.4 solution becomes available if evil Google start blocking Chrome > 97 UAs... Best regards !