VistaLover

@roytam1 : I smell SERIOUS trouble in the air: Remove Pale Moon from the Unified XUL Platform repository ( ... No need to guess whose work was that... )

That would be v2019.6.27 ; actually, AMO, again , made a big blunder there and marked the extension as Firefox 60.0+ compatible; but if you manually download the .XPI file https://addons.mozilla.org/firefox/downloads/file/3060290/https_everywhere-2019.6.27-an+fx.xpi and manually install it in FirefoxESR 52.9.x (drag-n-drop it in about:addons), you'll find it's still compatible: Nothing to apologise for... Simply another case of being misled by the wreck that Mozilla and AMO have now become...

FYI, Firefox versions 49.0.x-55.0.3 will download (and have internal support for) WVCDM v1.4.8.903 56.0.x-59.0.x will download (and have internal support for) WVCDM v1.4.8.1008 60.0.x-63.0.x will download (and have internal support for) WVCDM v1.4.9.1088 64.0.x-67.0.x will download (and have internal support for) WVCDM v4.10.1146.0 68.0.x will download (and has internal support for) WVCDM v4.10.1440.18 69.0.x-71.0.x will download (and have internal support for) WVCDM v4.10.1440.19 (currently supported version by Widevine licence servers; min OS requirement = Win7SP1) This list is only for the Firefox release channel, as the other branches (ESR, Beta/Developer, Nightly) will download different CDM versions... ... Nice detective work, BTW I'd expect you to go about installing Adobe Primetime CDM on browsers installed only in your Windows XP VM (sorry, I lost track: is that on your work or home setup?), as those browsers on Win7 don't need it for decoding purposes ; as Widevine CDM will only install under Vista+, I never considered the case of APCDM parallel install on Win7 ... Yes, that does look as the most plausible scenario! FWIW, my portable installation of FirefoxESR 45.9.1 32-bit under Vista SP2 has no issues automatically downloading/extracting/installing Adobe Primetime CDM v15 (NB, NOT v17) with the default value of about:config pref media.gmp-manager.url: https://aus5.mozilla.org/update/3/GMP/45.9.1/20170613084034/WINNT_x86-msvc-x86/en-US/esr/Windows_NT%206.0%20%28x86%29/default/default/update.xml Best wishes for the coming Holidays

... Latest version 2019.11.7 is still compatible with FxESR 52.9.x; I have it installed in the FxESR52 derived Tor Browser v7.5.6 : Huge thanks for your efforts!

... Of course I believe you ; but I insist that shouldn't happen ! To humour you, I just created a new/clean/pristine (call it what you want...) Serpent 52.9.0 2019.11.15 (32-bit) profile, and by simply going to about:preferences#content and ticking "Play DRM content", apparently a WVCDM v1.4.9.1088 download started in the background! By restarting the browser after ca. 5min, about:addons => Plugins shows the CDM correctly installed and activated: So, most probably, something is amiss in your current Serpent 52 profile (NB: Serpent 55 will still download and install WVCDM v1.4.8.903 !); make sure the pref media.gmp-manager.url is at its default value: https://aus5.mozilla.org/update/3/GMP/60.0/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml Under Win7 (x86), that above template should produce: https://aus5.mozilla.org/update/3/GMP/60.0/20191115221435/WINNT_x86-msvc-x86/en-US/release/Windows_NT%206.1.1.0.7601%20%28x86%29/default/default/update.xml ... where the direct link to the CDM (32-bit) is https://redirector.gvt1.com/edgedl/widevine-cdm/1.4.9.1088-win-ia32.zip You can always find the exact URI gmp-manager uses on your OS+Serpent 52 flavour by opening Browser Console before the CDM fetch begins (i.e. before checking "Play DRM content") ...

Glad to know ; perhaps you could apply a similar patch to latest version Kill Sticky 1.6 and upgrade to that, while you're at it? BTW, getting extensions from "unknown sources" is a major NO-NO in my world... ... You're not alone, sadly, but having been a Firefox Nightly tester in the past, I have always advocated here in these forums that the correct way is to always start with a pristine profile and then selectively and gradually transfer over things from the older one, especially when that older profile was touched by a different browser version/fork... Again, foiled by transplanting a Fx52 profile; those prefs don't normally exist in Serpent 52, they are just carried over from Fx52; Serpent has only one such pref, extensions.strictCompatibility, which defaults to false. I had no trouble installing that extension in Serpent 52.9.0 after having patched its install.rdf file to read: <em:minVersion>2.0</em:minVersion> <em:maxVersion>52.*</em:maxVersion> EDIT: The extension will install in St52 without patching its install.rdf file by modifying pref extensions.minCompatibleAppVersion;4.0 to extensions.minCompatibleAppVersion;2.0; but I'm not recommending this! Firefox 2.0 era addons are highly unlikely to function correctly with Australis era Serpent 52 (though this one does); you risk serious profile corruption by installing incompatible extensions, especially those targeting Fx 2.0; you won't know the outcome of such an experiment beforehand; you're on your own on this... BTW, this is a really old legacy extension, dating from 2010, which is currently only available through CAA (caa:addon/export-cookies), Export Cookies 1.2.1-signed.1-signed; but I have verified it still works! A similar extension from 2011 is also available in CAA, Cookies Export/import 1.0.1-signed.1-signed (caa:addon/cookies-exportimport), which does install as is on Serpent 52 ; might want to try that!

I have a patched (unsigned) Tab Tally v1.2.0 installed (in St52) and AFAICS it doesn't come with a "drop-down menu"; it does come with a toolbar button which, admittedly, doesn't stand out well inside FTDD's dark tab-toolbar (where I put it myself), but the number of open tabs is clearly shown in white - plus, when you hover over its button, a tooltip with dark background but light blue characters is shown: Which version of TT do you have installed? First, there's a legacy version (tab_tally-0.1.1-fx-windows.xpi) to be found inside CAA, the versions currently hosted on AMO are, ofc, all of the WE format; versions 1.0.0 to 1.3.0 are id-less, so, as per recent discussion, won't normally install in St52; version 1.4.0 (latest) is not id-less and does install, but it doesn't display the number of tabs in real time unless clicked (so that's why I avoid it!) ... ... OK, I see now you have probably installed v1.4.0, which does spawn a pop-up menu when left-clicked: It's probably possible via CSS to fix the fonts' colour so it would stand out behind the dark background, but am no CSS wizard ; instead, it should be more straightforward to patch the extension itself, should you wish to stick with v1.4.0 that is: Hint: Patch internal extension file popup.html as below: Line 10: - color: #444; + color: #00ADEE; Regards

WVCDM v1.4.8.903 was the version installed and supported by FirefoxESR 52.9.x on Vista+ (so in Win7, too); that version of the CDM was deprecated by Google on Sep 6th 2018; was your St52 profile migrated "dirty" from FxESR52? To update it further on St52 (for purely academic reasons now), with St52 exited delete all WV related directories inside its profile: .<profile>\gmp\WINNT_x86-msvc\gmp-widevinecdm .<profile>\gmp-widevinecdm then launch St52, load about:config and reset all WV related prefs media.gmp-widevinecdm.abi media.gmp-widevinecdm.autoupdate media.gmp-widevinecdm.lastUpdate media.gmp-widevinecdm.version ...make sure media.gmp-widevinecdm.enabled;true media.gmp-widevinecdm.visible;true Exit St52 once more, relaunch, in about:preferences#content make sure DRM content is ticked; visit https://drm.axinom.com/bitmovin-and-unified-streaming/ (or some other test site that requires the CDM) and St52 should prompt you to enable DRM (if not already) and inform you it's downloading "components"... Let it do so for 3 to 5 minutes, then restart St52; upon relaunch, WVCDM v1.4.9.1088 should be properly installed! Visit the test page again, only to find the content isn't being displayed ; Google have deprecated v1.4.9.1088 on Aug 14th 2019 : Being pedantic, with interface v10 of the CDM, Google have introduced some "re-versioning", omitting the first major version number, 1; latest WV CDMs are numbered as 4.10.xxxx.xx (e.g. 4.10.1440.19, 4.10.1582.1, 4.10.1582.2) - 4.10.1196.0 was the last Vista compatible CDM, all newer versions require at least Win7 ... Actually, if your findings coincide with mine, I'll expect you to find WV CDM vanish from both about:addons->plugins and about:plugins ; and yes, APCDM should still be there, but in a non-working state... * NB: Widevine CDM discussion doesn't apply on Serpent 52.9.0 used under Windows XP !

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) ...