VistaLover

Hello and welcome to the MSFN forums May I ask where did you retrieve an UNSIGNED version of the Kill Sticky firefox extension? This is of the Web Extension (WE) format and, as such, it can't be found inside the CAA addon, while ALL versions of it currently hosted on AMO are SIGNED BTW, the latest version there is 1.6, not 1.4; both claim to be Fx 52 compatible (but we've known from past examples that this is not written in stone, Mozilla may be - and have been - wrong, I'm convinced no-one of their staff manually tests released WEs with older - unsupported - Firefox versions ). Now, although Serpent 52.9.0 has retained whatever limited WE support was originally present in the UXP platform (contrary to official Basilisk 52 which has ditched WE support altogether ), Serpent 52 is NOT ON PAR with Firefox ESR 52.9.0 when it comes to WE support; several WE APIs were removed upstream (by MCP) from Serpent, so telling us that a certain WE addon works in Fx52 but doesn't in St52 isn't something conclusive... I decided to investigate myself, and Kill Sticky v1.4 is an id-less extension, a type of WEs that is not supported in Serpent 52.9.0/UXP out-of-the-box; if you've made the common mistake of transplanting an existing dirty Firefox 52 profile onto Serpent 52/UXP, then it's no surprise the extension got disabled... When changing browsers, always start with a new, clean profile! Trying to install Kill Sticky v1.4 in a Serpent 52 new profile, you'll be met by failure: As already mentioned, this is because it's an id-less WE; but you can patch the XPI file yourself to add the missing id, e.g. edit its manifest.json file like below: { "manifest_version": 2, "name": "Kill Sticky", "version": "1.4", "description": "Kill off the annoying floating things blocking the website you're trying to see", "icons": { "32": "icons/32t.png", "48": "icons/48t.png" }, "background": { "scripts": [ "background.js" ] }, "permissions": [ "activeTab" ], "optional_permissions": ["tabs"], "browser_action": { "default_icon": "icons/32t.png", "default_title": "Kill Sticky" }, "applications": { "gecko": { "id": "kill_sticky@mozilla.org" } } } Of course, that way you'll invalidate the extension's signature, so you can also remove directory META-INF! Have you reached so far yourself? Is this what you mean by an "unsigned" version of KS 1.4? I have no trouble installing my patched version of kill_sticky-1.4-an+fx.xpi in a clean profile of latest Serpent 52.9.0 (2019-12-06); its button shows up in the address bar, the addon is listed as ENABLED in the AOM, and it doesn't get disabled after several browser restarts : Slightly OT, but if you want an extension that can remove "web page overlays", then the legacy extension Behind The Overlay v0.1.6 (via CAA) works nicely in my St52 profile... I personally believe this is not "extension blocklist" related, but deleting a blocklist would only offer a temporary remedy, as the browser will automatically re-download it and place it within its profile... Best regards EDIT: Apparently, boolean user pref extensions.blocklist.enabled (defaults to true) controls the blocklist implementation; there exist several other extensions.blocklist.* prefs, one of which is extensions.blocklist.url; I guess by modifying its current value (string) to an invalid URI, you can stop the browser from fetching it... But I stress I don't believe myself the OP's issue is blocklist related... (but I could be wrong, once more... )

It is with sadness I have to report my favourite Bit Torrent client of close to 6 years now, qBittorrent, has dropped Vista (and probably XP) support! I was running the portable PAF version and just found out the hard way, after accepting a prompt to upgrade to the recently released new version 4.2.0: Inspection of the main x86 executable with Dependency Walker reveals further missing function calls in Vista's system files: in SHELL32.DLL Shell_NotifyIconGetRect in MFPLAT.DLL MFCreateMFByteStreamOnStream in USER32.DLL ChangeWindowMessageFilterEx CloseTouchInputHandle GetTouchInputInfo IsTouchWindow RegisterTouchWindow UnregisterTouchWindow The application is compiled with the Qt Framework, last version of which to be compatible with Vista+XP is 5.6.x (I think 5.6.3 was the last release of the 5.6 branch); the app's code is open-source, published on GitHub: https://github.com/qbittorrent/qBittorrent Browsing that repo, it becomes evident that the team of devs willingly moved past NT6.0 support, e.g. https://github.com/qbittorrent/qBittorrent/commit/5d0d8a0b7b032ed6f850325921eddc2f7303d9a8 https://github.com/qbittorrent/qBittorrent/commit/a4b9a4d9da9c9479eb1e63c8b8157aa4209c627c https://github.com/qbittorrent/qBittorrent/commit/7276a79cefe00f3e82fec8760ec876aa8a276df0 https://github.com/qbittorrent/qBittorrent/commit/2f0ae7a7d8c53d8c1d1bee08d61e5dcb28cfd61b https://github.com/qbittorrent/qBittorrent/commit/3ab2fe907f9519a9a90e072576ba6cfbbd52857d https://github.com/qbittorrent/qBittorrent/commit/74fc86e2ab2896bff9e90ab710b722027f2b9678 where the last commit dates from March 17th (!) 2019 and contains the changelog lines: - WINDOWS: Drop support for < Windows 7 (snip) - OTHER: Raise minimum Qt version to 5.9.0 (sledgehammer999) Another reason I did not see that coming was the fact the pre-release alpha builds, v4.2.0alpha, had been available only in the x64 architecture (on their site: "For Windows, only the 64-bit build is available for the alpha release."), so I couldn't test them prior to the official 4.2.0 x86 release... Had I been more cautious, I could have 1. spotted, between the lengthy release notes of 4.2.0, and in the downloads page itself So, I guess I'm stuck at the last version of qbittorrent that's Vista SP2 compatible, which is v4.1.9.1 https://www.fosshub.com/qBittorrent-old.html?dwl=qbittorrent_4.1.9.1_setup.exe https://sourceforge.net/projects/qbittorrent/files/qbittorrent-win32/qbittorrent-4.1.9.1/ Portable version, in PAF format: https://portableapps.com/downloading/?a=qBittorrentPortable&n=qBittorrent Portable&s=s&p=&d=pa&f=qBittorrentPortable_4.1.9.1.paf.exe Many years ago, I'd be using Shareaza (remember that?) as my P2P client, for both ed2k and bittorrent shares, but when emule went out of fashion, I switched to μTorrent for the BT network... But when that turned into a horrible adware , I gladly switched to qbt, which offers pretty much the same GUI (minus the adds...); plus, its Python powered search feature is not to be missed... Other BT clients I had also tried in the past, showing a preference to Tixati ; but I stayed with qbt ; I don't want to derail this thread, but should I be considering switching to another BT client for the duration I'm still on Vista SP2? What is your personal experience with the other choices?

Welcome to MSFN Forums ; judging by that screenshot, what you're after is a "Complete Theme" Several Complete Themes do exist for New Moon 28 in the official Pale Moon extensions repository: https://addons.palemoon.org/themes/ However, if you want one for Serpent 52.9.0, then only one is officially available: https://addons.basilisk-browser.org/themes/ and to add insult to injury, that unique one only works correctly on Win7+ (it contains specific Win7+ CSS code ) You'll have better luck installing a Firefox 52 compatible complete theme; however, 1. AMO (addons.mozilla.org) has had all Complete Themes removed since Quantum (Fx 57.0+) was released... 2. The ill-fated, now taken down, legacycollector site did not list any Complete Firefox Themes 3. Likewise, the CAA (Classic Addons Archive) extension does not contain any reference to Complete Firefox Themes (a very unfortunate/poor decision by its maintainer, if I may say so myself) ... Your only source of Complete Firefox Themes currently is what has been salvaged from AMO by the web archive: http://web.archive.org/web/20181124130244/https://addons.mozilla.org/en-US/firefox/complete-themes/ You can start from there and hopefully find your way to an archived XPI theme file... Mine (depicted in your screenshot) is FTDeepDark v14.3 (slightly patched to accommodate minor Serpent issues...): https://web.archive.org/web/20180729192834/https://addons.mozilla.org/en-US/firefox/addon/ft-deepdark/versions/?page=1#version-14.3 Direct link to XPI file: https://web.archive.org/web/20170829121054if_/https://addons.cdn.mozilla.net/user-media/addons/295337/ft_deepdark-14.3-fx-windows.xpi?filehash=sha256%3A1a92752850c0e90b0962eec6b0d5e5343c703d4a8b64905d756a82621ef5b5c8 Regards

Most unfortunately, I can reproduce ; and it isn't only the Adobe Primetime CDM affected, as reported by @dencorso, but also the Widevine CDM too, which is installed and visible under Vista+; Widevine CDM v1.4.9.1088 is currently broken since August 13th 2019, due to Google changes - effort is underway by MCP to restore Widevine support in official Basilisk ( see here ), which is currently hitting a deadend, but any success won't benefit Vista users of Serpent, as updated Widevine DLLs don't run on Vista and require Win7+; still, having a working implementation of WV on Serpent would certainly benefit St users on Win7+ I normally don't have Adobe Primetime CDM (APCDM) installed in my Serpent 52 profile, but to humour @dencorso I did correctly install it (v17) and made sure I disabled the other h264/aac decoders: media.wmf.enabled;false (Vista's native WMF decoder) media.ffvpx.enabled;false (Serpent's bundled FFmpeg decoder) while I made sure media.gmp.decoder.enabled;true (APCDM's decoder) Widevine CDM (WVCDM) v1.4.9.1088 is also correctly installed. Extended testing reveals that: A. 2019-11-15 Serpent win32 build is the last good build where: 1. WVCDM appears installed in both "about:addons => Plugins" and about:plugins : 2. APCDM's decoder properly works for MP4 HTML5 video; e.g., first test clip on https://tekeye.uk/html/html5-video-test-page (1: HTML5 MPEG Video Test) B. By simply updating to the next Serpent 52 build, 2019-11-22, one discovers that it's the first bad one, since: 1. WVCDM magically vanishes from both "about:addons => Plugins" and about:plugins : 2. APCDM, while still present in both "about:addons => Plugins" and about:plugins, simply quits functioning as a h264/aac decoder (as reported by dencorso): @Mathwiz : Could you be so kind as to confirm my tests, preferably on Win7 where Widevine CDM is visible (thanks in advance ) ? ====================================== Now, examining more closely related code, MCP did remove APCDM support in official Basilisk in UXP #1259 ; the bulk of the patches would have landed in the 2019-11-15 build, as per but you did revert those (more accurately, did not apply at all in your custom branch), as per ... furthermore, the reversion has been successful, as the 2019-11-15 build is, according to my analysis above, the LAST GOOD one The MCP devs did not revisit issue #1259, except for https://github.com/MoonchildProductions/UXP/pull/1293 (Adjust Widewine strings after removing Adobe Primetime support) and thus https://github.com/MoonchildProductions/UXP/commit/36c81a9 This would have normally landed in the 2019-11-22 build of Serpent 52: while you did not technically revert that, you added your own version with a slightly modified code: https://github.com/roytam1/UXP/commit/e50e93c Since I'm not a code wizard by any stretch of the imagination, I can't be certain that the culprit for the issues reported here lies within that commit of yours... What is absolutely certain is the offending changeset(s) lives inside the changelog (in your custom UXP branch) between Serpent build 2019-11-15 and build 2019-11-22 ; please, at your discretion, investigate further ... Because, while you took the extra effort to keep APCDM support inside Serpent 52 alive (against MCP's agenda), not only did we end up with a crippled APCDM installation, but also Widevine took an unexpected hit and did a disappearing act... Thanks for your time reading this long report, hopefully you'll get it sorted out! Many thanks, as ever, for providing your forks to the community! Best regards

Am afraid no-one else but you can answer that question ... Only you know the exact configuration of your OS/system and your browsers - the rest of us here trying to help are not clairvoyants; and, as you can imagine, all have our personal issues in both digital (!) and real life... So, when asking for help, be extremely precise about your CPU/OS and browser; and in the case of browser, type/version/architecture/EXTENSIONS/user-modified prefs are of high importance! Then, of course, there are cases where manifested issues are due to factors beyond your control, e.g. hick-ups at your ISP or server-specific outages... Many things can go wrong (but, thankfully, few do at the same time...) ! You have proclaimed your "love" for using Proxies, VPNs and privacy related tools; a shot in the wild, but maybe one of these is the cause for your issues? And I'll emphasise once again that the first troubleshooting step when it comes to browser problems is to START WITH A BRAND NEW (CLEAN) PROFILE (no extensions, default "GUI" and "hidden" settings), using your DIRECT ISP connection - if you can't reproduce the problem there, then you know it's caused by something YOU did... FWIW, all images load fine here: FWIW, plays fine here (Serpent 52.9.0): This is only used within a WebRTC context (not supported in New Moon, but is supported in Serpent 52/55); if you're on Windows XP (with SP3 I presume, fully updated until the EOS MS updates), then by default New Moon 28/Serpent 52.9.0/Serpent 55.0.0 will come with a bundled h264/aac decoder (in the form of a custom ffvpx library - make sure media.ffvpx.enabled (in about:config) is in its default value, true); so you shouldn't have MP4 video playback issues...

The LIVE (i.e. non-archived) edition of the Tek Eye test page loads and works fine here (Serpent 52.9.0) : So, whatever issues you're having must be at your end...

Same here; IMHO, I don't think that would be cause for any breakage... I checked AniView specifically: Update checks are made via the CodeDead.UpdateManager.dll file; in https://github.com/CodeDead/AniView/commit/2e9cb99 it appears it is accessing the following URI: https://codedead.com/Software/AniView/update.xml That one correctly loads in Serpent 52.9.0 through TLS v1.2: <Update> <MajorVersion>1</MajorVersion> <MinorVersion>5</MinorVersion> <BuildVersion>3</BuildVersion> <RevisionVersion>0</RevisionVersion> <UpdateUrl>https://codedead.com/Software/AniView/AV_setup.exe</UpdateUrl> <InfoUrl>https://codedead.com/?p=2217</InfoUrl> <UpdateInfo> Version 1.5.3 is now available! Please click the download button to download this version. </UpdateInfo> </Update> ... but DOESN'T LOAD in IE9 (TLS v1.2 enabled) https://www.ssllabs.com/ssltest/analyze.html?d=codedead.com&s=185.94.230.248&latest shows that the server is configured to ONLY connect through TLS v1.2 with only 4 cipher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits RSA) FS 256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA) FS 128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 128 ... NONE of which are supported in IE9 "CodeDead.UpdateManager.dll" loads system network+crypto resources to access that URI (dependency walker reveals it loads, among many others, crypt32.dll, wininet.dll, secure32.dll, cryptui.dll, ieui.dll, ncrypt.dll, bcrypt.dll), so it appears it can't establish the secure connection that way and aborts... As per my analysis above. at least AniView.exe+CodeDead.UpdateManager.dll require just TLS v1.2; as for more testing, I'd be curious to know whether its "Update Check" feature works OK with .NET FW 4.8 on Win7+; if not, the developer should be made aware... Best regards

Well, I know you posted that app as a test for correctly installed .NET FW 4.8, but that same app can be launched with only .NET FW 4.6.1 installed; just download the portable version, patch file AniView.exe.config (L8-L10) to read <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1"/> </startup> and voila: However, what doesn't work with .NET FW 4.6.1 is the "Check for updates" feature (and thus, I suspect, also the "Automatically check for updates" one...) : Can you confirm update checks work as intended with .NET FW 4.8 force-installed?

... Yes, thank you .... Actually, the last working web archive capture of the original page is from last May 5th 2019: https://web.archive.org/web/20190505022505/https://www.quirksmode.org/html5/tests/video.html ================= EDIT (09/12/2019): As pointed out in a following post by @msfntor, it appears that "web.archive.org" have not captured the link to the last video (Ogg/Theora HTML5 test) in a reliable fashion ; however, that last test should be of little importance now, as almost no-one uploads these days video encoded with the Theora encoder (which is indeed a shame, as the encoder is open source and free); besides, Mozilla based browsers have had native support for Theora since long ago (it's bundled with the browser) ... Should you insist to verify Theora (in OGG container) support, the previous-to-last "web.archive.com" capture (Apr 26th 2019) of the original page has that test in working condition: https://web.archive.org/web/20190426003407/http://www.quirksmode.org:80/html5/tests/video.html ================= The test clips were removed (by the page owner) sometime after that date, at the request of his ISP, 'cause they were eating up huge chunks of bandwidth... Sadly, with a working capture available, this bandwidth consumption is now transferred over to web.archive.org (so I'd be "easy" on them... ) .

... This was addressed before in these threads - youtube (read Google) have themselves disabled the checking functionality on that page, in early autumn of this year ; to them, it's redundant now, since all the latest versions of the browsers they endorse returned all 6 blue checks... They DON'T CARE about older versions of browsers run on older, unsupported, Windows OSes... Workaround: 1. Use the last archived edition of the page (it actually works even now!) YouTube HTML5 Video Player http://web.archive.org/web/20190805082454/https://www.youtube.com/html5 2. Use an alternate checking service: Tek Eye HTML5 Video Test Page https://tekeye.uk/html/html5-video-test-page https://tekeye.uk/html/play-video-in-html5 http://demo.nimius.net/video_test/

... Unfortunately, this link currently only downloads a file sized a mere 32 bytes...

Tried it on Vista SP2 32-bit and yes, AERO works nicely ; so does the Task Manager; but every tab crashes when it tries to load ; I've seen this happen when I tried to run Google Chrome 51 (release) under Vista... My wholehearted wishes towards the success of this project (but it'd be a shame if it succeeds on XP but not on Vista... ) EDIT: Checking with dependency walker, it appears there are still missing function calls under Vista SP2; e.g. chrome_child.dll looks for function QueryUnbiasedInterruptTime in Vista's kernel32.dll system file; but that function requires Win7+'s version of kernel32.dll...

... This specific pref, which I DID NOT mention in my attempt to help you (once more...), is to enable you to install UNSIGNED extensions in your Firefox[Nightly]ESR v45.9.18 copy; FALSE is its default setting; so, when starting with a new/clean profile, there was nothing for you to set beforehand! In any case, that pref you brought up has nothing to do with language packs, which are unsigned! And, pray tell, what is the message Nightly (45.9.18esr) spawns? Installing a compatible language pack has nothing to do with having an SSE only processor; if you're able to launch and run the browser, then you should be able to install a langpack on it! The language pack, through the proper installation process, would end up in the "extensions" subfolder inside your nightly-45.9.18 profile folder (which, needless to say, should be writable by your user account); to locate your profile folder: about:support => Profilordner => Ordner anzeigen You've also asked how to tell which version of Firefox[Nightly]-45.9.18 is currently running in your system: simple answer is the latest you have installed in your system, if you only have that one (the latest) and only that one present in your system; don't keep various versions around, install the new one OVERWRITING the previous one! Sadly, the Uber Firefox popup doesn't notify about build ID (but this should be fixable in code, should @roytam1 indulge...) and only displays 45.9.18; but you can again use "about:support" to have an indication of the build ID; the latest available compile, file "firefox-45.9.18-20191123-a1b817dab-win32-sse.7z", has a build ID=20191122161113 (this number is actually a timestamp in ISO format => Nov 22nd 2019, 16:11:13), so its "complete" version would be 45.9.18 (32-bit) (2019-11-22): As for a German language pack for @roytam1's Firefox 45.9.18 (SSE-only compatible) fork, the screenshots already posted are a testament to my original guide to you... I can assure you that the de.xpi file I linked to previously is FULLY compatible and installable in a new/clean profile of the browser, where the only extension installed is uBlock0-legacy 1.16.4.11: I couldn't begin to imagine why it won't install in your case... What is consistent with your many other reported issues in these forums is that your OS/system is fundamentally borked... Adding to whatever issues at the OS level (hardware, permissions, etc.), you probably also have corrupted browser profiles (possibly due to launching/mixing the same profile with different browser versions, due to incompatible extensions, God knows what...), so, though I genuinely wish to assist you, it's becoming quite hard to do... If you can download the de.xpi file in another browser/system, try opening about:addons in your Nightly-45.9.18 browser and drag-and-drop it there; it should install (most certainly in a clean profile)... Zuss

You need to install the Adobe Primetime CDM. As posted in the past, since my old Intel Core 2 Duo processor (Merom) does support the SSE2 instructions set, I've not had the curiosity to try Firefox (Nightly) 45.9.x on this laptop, happily using the UXP forks, rarely Serpent 55.0.0. But, from memory, I think your quoted suggestion regarding RoyTam1's Firefox 45.9.18 under Windows XP is flawed... 1. EME support in the Mozilla Firefox browser in the form of the Adobe Primetime CDM first materialised in Firefox 38.0; the CDM targeted Windows only OSes and was only visible from Vista SP2 onwards ; in a later Firefox version (unsure exactly which ), it was made available to Windows XP, too; but the makers, Adobe, didn't want to support APCDM for DRM purposes under XP, especially since the initial implementation of it, v15, had issues on that OS; the Mozilla team couldn't make their minds up whether to keep the CDM on XP or not: they kept un-hiding and then hiding it again for a certain period (), especially when the next iteration of it (v17 - v16 was only 64-bit) was offered by Adobe (with lesser issues on XP): Unhide Adobe GMP on Windows XP https://bugzilla.mozilla.org/show_bug.cgi?id=1234099 Make Adobe GMP available to Windows XP users in Firefox 45 and later https://bugzilla.mozilla.org/show_bug.cgi?id=1234100 GMP crash or garbled HE-AAC audio when playing MP4 decoded using Adobe's GMP https://bugzilla.mozilla.org/show_bug.cgi?id=1236756 Hide Adobe GMP on Windows XP in Firefox 46 and 47. https://bugzilla.mozilla.org/show_bug.cgi?id=1265928 On supported OSes, the CDM was automatically downloaded and installed in Fx <=46.0; in v47.0-51.0, in new profiles, it was only downloaded and installed on demand, when visiting a media site that asked for it (although previous installations of the CDM in existing "dirty" profiles, put there under Fx < 47.0, remained unaffected). Support was officially disabled by Mozilla in Firefox v52.0 for all WinOSes, because, by then, the Audio-Video media industry had completely moved over to (Google acquired) Widevine CDM for enforcing DRM on copyrighted content (the WVCDM first appeared in Firefox v47.0 and is visible on Vista SP2+) ; in Fx 52.0/ESR 52.x.x, the APCDM would no longer be downloaded on demand in a new profile, previous installations of it get disabled; but the underlying support code was still left intact; that code was finally completely removed in Fx v53.0 (compatible with Win7+). At least on Vista (SP2), FxESR 45.9.1 downloads and installs APCDM v15 automatically: 2. From a previous exchange with Roy in these forums, it was made known to me that to get proper h264/aac decoding support on that fork under XP, needed for HTML5 embedded MP4 video, you'll have to download and place inside the browser's main installation folder (not its profile) the LAV filters DLLs that were made available previously to get the same feature for the New Moon 27.x.x/Tycho fork: @roytam1 : Post #1 in the original thread is now locked, so probably you can't edit that yourself now (nor can I properly quote the above excerpt ); perhaps a mod can, or you could add that FxESR 45.9.x specific bit on post #1 of this second (continuation) thread ? Thanks! Sadly, even with the above decoders installed, it's not definite Twitter clips will play OK; they use MPEG-DASH and/or HLS streams, which require MSE support in the browser; I'm not sure how mature is Fx45's MSE implementation for those vids to work...

... I don't want to derail this thread, but I recently became aware of the following extended article: Mozilla - Devil Incarnate It's certainly an eye opener for those that have little to do with Mozilla internals, most certainly a recommended read... Having been a Firefox Nightly tester (from versions 27.0a1 all the way to 46.0a1, then briefly from versions 51.0a1 to 53.0a1=EoS for Vista SP2 ), having been a subscriber on both Bugzilla and the Nightly Testers mailing list, I can assure you the attitude exhibited by most Mozilla devs towards anyone in the user base not condoning their "devine" decisions is pretty accurately detailed in the linked article... E.g., I, with several other Vista users, tried - in vain - to persuade them not to put Vista in the same boat as XP and, hopefully, extend Vista support further, past Fx 52 (up-to-version 54.0 could've been easy), but was met with a brick wall - their pretenses were that Vista was too much of a burden to support resource-wise and they insisted I switch to Linux; and that was at a time (circa end of 2016) when Firefox users on Linux were 1/20th of the Vista users... I recall I persevered and tested the whole 53.0a1 development cycle on my Vista machine many days after they made everything in their power to block 53.0a1 on Vista; when the installers blocked the OS, I switched to the "zip" packages and continued telling them that their - then - current code remains Vista compatible and that they were wrong to drop Vista support so soon - they were really mad and unsure as to how I was able to pull this through, until another user pointed to them (!) that the standalone executables (firefox.exe) would launch on NT6.0; then they quickly patched that by raising subsystem version to 6.1 in the EXE's PE header; but I used PE_patch (or similar tools) to undo their artificial block and set it back to 6.0; they went livid when I posted with a Nightly 54.0a1 version running on Vista SP2: ... But eventually they started using their new shiny toy, Rust programming language, which, when compiled, only targets Win7+, thus my 54.0a1 testing experiments ended abruptly... In fairness, very few code authors like it when their coding decisions are being challenged by the user base; I've witnessed this in many instances and this is certainly true with Moonchild Productions team, too; simply browse their official forum and GitHub tracker, where any "questioning" voice (outside their narrow circle of devs) is quickly muffled (more politely by Moonchild himself, brutally by you know whom...) But in the end, if I had to choose between a Google product and a Mozilla one, the lesser of two evils is the obvious choice...

The latest pre-release language packs targeting the Pale Moon unstable channel (at v28.8.0a1 atm) have been uploaded just minutes ago: https://github.com/JustOff/pale-moon-localization/releases/tag/28.8.0_RC1 They should be natively compatible with New Moon 28.8.0a1 (i.e. without having to modify install.rdf file) !

I would advise against this setting for those combinations of Windows OSes (Vista SP2 and up) and GPUs where hardware video (h264) decoding is actually possible and the default; disabling HVD delegates h264 decoding to the CPU, which may have (depending on the CPU) a significant performance toll (especially on high res videos) ... Additionally, I'm not quite sure whether the above "media." pref has any actual bearing on XP (where HVD via WMF is not possible) ...

Yes, I have verified that on a Win7SP1 64-bit laptop, where the same Serpent 52.9.0 32-bit build will have no problem playing back Twitter gifs with Win7's native WMF h264 decoder , whereas on Vista it would barf, as already posted... FWIW, Vista's WMF implementation (which requires SP2 to be present) is notably inferior to the one present in Win7; Win7 OEM was released with native h264 decoding support present, while on Vista it was implemented via post-SP2 Microsoft updates (and, I suspect, as best as Vista's then internals would allow... ).

... But I think you neglected to include in your custom changes: - Hidden preference to toggle addon version in addon manager which did land in the 20191123 builds of both Serpent 52 & New Moon 28 (PR authored by @Mathwiz )

Fellow Vista Home Premium SP2 32-bit user here ; on Vista, there seems to be a conflict/incompatibility between the native WMF h264 decoder (not present in XP) and certain gif formats, like the Twitter ones ; the ffmpeg-based h264 decoder present inside @roytam1 's custom-patched ffvpx library is still capable of rendering those gifs though, but has a lower value (in the preferred order) and is thus not used by default on Vista (while it is on XP, which lacks WMF); so, your issue is Vista specific... To view such Twitter gifs on Vista, temporarily set (in about:config) media.wmf.enabled to false and reload the twitter page; the gif should play now (because ffvpx takes over...) NB: I'd advise against making this a permanent pref change, as the WMF framework is better suited for media playback integration with UXP browsers under Vista (e.g., if your gfx card supports hardware (i.e. GPU) h264 decoding, it can make use of that, while ffvpx always uses software (i.e. CPU) decoding) ! Best regards

This was posted in the past (in the now closed original thread), but the official Mozilla langpack for FxESR 45.9.0 should do: https://ftp.mozilla.org/pub/firefox/releases/45.9.0esr/win32/xpi/de.xpi Install, restart browser, in about:config set general.useragent.locale;de, restart once more...

... And a nice find I stumbled upon just now (!) :

(Continuing, hopefully not for long , OT discussion about media playback capabilities of Otter Browser under XP/Vista) Many thanks for that link, which also uncovered the rest of the official Otter Browser Forum for me ; thing is, I only keep Otter here as an oddity item, not investing serious time in educating myself about its peculiarities and overall development ... I did read, though, the whole linked thread and have to say the real money is on the very last post there, by member maxxproff : It's in fact that huge (77.4 MB) DLL alone that gives the "-xp" (QT 5.6.2 based) Otter builds h264 (and VP8) decoding support; so this is a big improvement compared to the stock XP/Vista builds But that support alone will only allow for the reproduction of standalone MP4 files (local files or ones streamed via progressive download, such as 360p & 720p avc1+aac youtube encodes); however, as also pointed out in that post, with this solution there's still no support for MSE, despite setting about:config => QtWebKitBackend => EnableMediaSource : Yes So, MP4 files streamed over MPEG-DASH , like youtube's higher resolution (e.g. 1080p+) encodes (separate video/audio streams), won't be played back (actually, they don't appear as options at all...). This is made clear using the (now archived) YouTube HTML5 test page: Inside the blue-lined rectangle, functions enabled by the standalone libgstlibav.dll file... That fix has been really appreciated though, many thanks indeed! Cheers!

It's there for me, under "Connected Domains": Adding and enabling the filter list you linked to, blocks it (green colour turns to red) ! Screenshot of the uB0 logger with the tracking script blocked: I've opened that actual script inside a private tab and it's indeed nasty...

Otter v1.0.81[weekly300-xp] uses OpenSSL 1.0.2o, so that fact alone empowers it with support for a plethora of cipher suites (and TLS versions); not only a great number of cipher suites are already enabled by default, you can also add additional ones (out of the many OpenSSL supports): However, the xp (and Vista) compatible package (compiled with QT 5.6.2) uses gstreamer as the media backend; because of patented decoders (h264, aac) licence issues, the distributed binaries lack support for h264 decoding and this is a deal-breaker for me in today's media-rich web; the Win7+ packages are compiled with a higher QT version (5.13.1, requires Win7+) which comes with support for the native WMF framework (present in Vista+), enabling access to OS provided patented decoders; to cut a long story short, Otter v1.0.81 on XP/Vista will load fine cote.co.uk, but won't play the background video... The reason Opera 36/XP doesn't, also, play the background video is quite similar; the browser (unlike Chrome 49) doesn't come bundled with a h264 decoder, the OS has to provide that through WMF; but, as you know already, XP lacks WMF . FTR, Opera 36/VistaSP2 does load the site and does play the background video... Best regards