VistaLover

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 !

There's something wrong with the latest (v2025.07.11) youtube-dl.exe build downloaded from GitHub: https://github.com/nicolaasjan/youtube-dl/releases/tag/2025.07.11 https://github.com/nicolaasjan/youtube-dl/releases/download/2025.07.11/youtube-dl.exe 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.11 [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: {} Traceback (most recent call last): File "C:\Users\nico\Desktop\youtube-dl_source\youtube_dl\update.py", line 48, in update_self File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 470, in open File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 580, in http_response File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 502, in error File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 442, in _call_chain File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 685, in http_error_302 File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 470, in open File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 580, in http_response File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 508, in error File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 442, in _call_chain File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 588, in http_error_default urllib.error.HTTPError: HTTP Error 404: Not Found ERROR: can't find the current version. Please try again later. The previous compile, of version 2025.06.26: https://github.com/nicolaasjan/youtube-dl/releases/download/2025.06.26/youtube-dl.exe , behaves as expected: 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.06.26 [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: {} youtube-dl is up to date (2025.06.26) Many thanks for your ongoing efforts towards maintaining support for "our" older OSes ...

https://github.com/advisories/GHSA-mj9c-f5v6-7665 Severity: High (8.1/10) https://chromereleases.googleblog.com/2025/06/stable-channel-update-for-desktop_30.html Manual mitigation, at the expense of performance, if you don't want to update: https://github.com/Alex313031/thorium/issues/1024#issuecomment-3038992237

Out of curiosity, I got myself a HK IP address and then tried to load: https://repo.palemoon.org/MoonchildProductions/UXP This is what I got: It would be far-fetched to think (would it? ) that MC specifically blocked access to his Gitea instance in Hong Kong, where roytam1 resides, as a means of thwarting further development of the UXP "XP forks", that he so much despises... In any case, @roytam1 are you behind the GFW in HK? Can you not use a geo-spoofing application (VPN, VPS, DNS, Shadowsocks, etc. ) to acquire, e.g., a European IP address and properly access RPO? Worst case scenario, one of "us" here could send you a tarball of the proper UXP repo, though currently this stands at ca, 252 MB:

RPO (repo.palemoon.org) is a server owned and paid-for by Moonchild himself; Gitea is just the version control software deployed on that private server to manage source development for UXP, Pale Moon and related projects; it's what is called a "private (self-hosted) Gitea instance" ; on the Anubis test page itself, one can read: ... so I believe MC is mainly concerned with excessive bandwidth consumption; please also note that he had already implemented geolocation-based ACLs (access-control-lists) to counter automated DDoS attacks and, as a consequence, in Hong Kong (where our own roytam1 lives ) RPO is blocked ...

... This only means further/wider proliferation of such MITM anti-crawler "services", with the web becoming even more "unpleasant" as time moves on (with a greater impact, of course, on older browser engines, on old/weak H/W); what's the point of having 500 (or more) Mbps fiber internet speeds when every tab you open in your browser will need additional time to pass complex JS tests? FTR, I keep, for historical purposes, a "portable copy" of NM27 (not the last one published, though), which isn't able to pass the Anubis test (e.g., on RPO Gitea repos); and even Serpent 52 struggles passing that test, especially if I don't disable "security/privacy"-oriented solutions (extensions and/or userscripts); privacy also falls victim here, because you're given no other choice on such web-policing "services": either "open" your "privacy fences" or be denied access to the site you're after ... This is all depression-inducing ...

https://repo.palemoon.org/MoonchildProductions/UXP/issues/1721 https://repo.palemoon.org/MoonchildProductions/UXP/commit/c030a50228349fa1b2c0b4fbc2e83752324dd4d7 https://www.palemoon.org/support/global-privacy-control

@IXOYE : In NM28, a SSUAO for ARTE is needed; posing as FxESR-128 on Win10x86 works for me in order to load its English homepage : general.useragent.override.arte.tv;Mozilla/5.0 (Windows NT 10.0; rv:128.0) Gecko/20100101 Firefox/128.0 ...

Upstream (i.e. UXP/Pale Moon) are already aware: https://forum.palemoon.org/viewtopic.php?t=32222 https://repo.palemoon.org/MoonchildProductions/UXP/issues/2721 Here a workaround is kindly offered (requires an additional extension ) ...

... Respectfully, I beg to disagree ... While 128 is the currently supported Firefox ESR version, the previous ESR (Firefox 115) is also supported, for the sake of Win7/8/8.1 users (support will end, supposedly, next September); the minimum Fx version supported by AMO, is, thus, 115 ... FirefoxESR-115 has the same User Agent String as the release channel Fx-115 had, which was (e.g., on Win7 SP1 32-bit): Mozilla/5.0 (Windows NT 6.1; rv:109.0) Gecko/20100101 Firefox/115.0 For Firefox versions 110-119, the "rv:" value was frozen to 109, due to a Mozilla bug ... Below is r3dfoxESR-115.13.0 (a FirefoxESR-115 fork that is able to run under Vista SP2) with a SSUAO of: general.useragent.override.addons.mozilla.org;Mozilla/5.0 (Windows NT 6.1; rv:109.0) Gecko/20100101 Firefox/115.0 visiting https://addons.mozilla.org/de/firefox/addon/traduzir-paginas-web/ : When the above SSUAO is "lowered" to Fx-114, general.useragent.override.addons.mozilla.org;Mozilla/5.0 (Windows NT 6.1; rv:109.0) Gecko/20100101 Firefox/114.0 ... the issue you reported occurs: So, probably until the end of Sep 2025, Firefox 115 is now the minimum... Kindest regards.

https://github.com/ytdl-org/youtube-dl#video-selection --playlist-start NUMBER Playlist video to start at (default is 1) --playlist-end NUMBER Playlist video to end at (default is last) --playlist-items ITEM_SPEC Playlist video items to download. Specify indices of the videos in the playlist separated by commas like: "-- playlist-items 1,2,5,8" if you want to download videos indexed 1, 2, 5, 8 in the playlist. You can specify range: " --playlist-items 1-3,7,10-13", it will download the videos at index 1, 2, 3, 7, 10, 11, 12 and 13. ... Then make sure you have perused ALL available CLI options (aka switches) for BOTH; for youtube-dl (often abbreviated as just yt-dl), the place to start is: https://github.com/ytdl-org/youtube-dl#options FWIW, yt-dlp is a more "advanced" tool (with more complex syntax and options), that requires some additional expertise on the part of the user ; yt-dlp is not guaranteed to continue to work under XP (and Vista) after this October, when its devs drop py3.9 support (to this day, no py3.10+ fork has been made public that can run on NT 5.x/6.0 ) ....

( Happy Easter to all those who observe it ! ) New r3dfox releases have appeared on its GitHub repo : https://github.com/Eclipse-Community/r3dfox/releases/tag/v128.9.0 ... and: https://github.com/Eclipse-Community/r3dfox/releases/tag/v136.0.4 Many thanks to the maintainer! ...

FYI: https://forum.videolan.org/viewtopic.php?f=14&t=141939 https://forum.videolan.org/viewtopic.php?p=460965#p460965 https://forum.videolan.org/viewtopic.php?f=14&t=160467 The "portable" directory will be populated with below content (settings): ./vlc.exe/portable/vlc/vlc-qt-interface.ini (GUI related settings) ./vlc.exe/portable/ml.xspf (playlist) ./vlc.exe/portable/vlcrc (app related settings) The "portabilised" (nightly) VLC instance will load its settings from said "portable" folder and won't ever touch (mess with) VLC settings extant in %APPDATA% ... Regards.

... I'm well aware , so that's why you weren't quoted ...

aka & nesting selector ... Partial (or full) support is behind custom (experimental) flags on earlier versions of both browsers: Probably useful info for people still on Win7 (where Cr109/Fx115esr are the last officially supported versions) ... https://repo.palemoon.org/MoonchildProductions/UXP/issues?q=CSS&type=all&state=open doesn't display an open issue for this CSS feature under UXP ... Additionally, the footer on https://techcommunity.microsoft.com/ (as well as other content after the "Additional Help & Learning Resources" bit) isn't rendered properly (it renders as a vertical left-hand column) in UXP, possibly the same issue, too ... FWIW, "Microsoft pages" do not contain only stuff exclusive to Win11 , once the nesting selector makes its way onto other web "frameworks" and sites, the breakage on UXP browsers will become more common ...

... Not to jinx things or anything , but you better finish your tests soon ; at the rate we're going, Google have been able to "break" youtube-dl (by serving "specially" crafted JS yt-players) every other day or two ...