VistaLover

Finally, some good news! After a faulty 1.367.4xx.0 series of WD definitions, which included buggy mpasdlta.vdm files of versions 1.367.413.0, 1.367.415.0, 1.367.423.0, 1.367.432.0, 1.367.435.0, 1.367.447.0, 1.367.457.0, 1.367.472.0, 1.367.487.0, 1.367.491.0, WD defs of v1.367.494.0 and higher are, once again, "OK", i.e. they no longer cause WD's Windows service to crash under Vista SP2 ; series "5xx" is already "out", I successfully ran a "Quick Scan" with v1.367.502.0 : ... I won't go as far as saying that MS staff monitor this thread (), but either via internal testing or via some other party reporting it to them, the issue has been identified and mitigated... Until the next c*ck up and until Jan 2023 (when I expect WD+MSE standalone defs to be retired by MS) ...

A definitive "CloudFlare Browser Check" is trying to log-in to GitLab: https://gitlab.com/users/sign_in BTW, this happens when site admins - who are CF clients - have enabled a feature called "Browser Integrity Check" (BIC) ... CF have recently abolished the CAPTCHA challenges as part of BIC, replacing them with automated checking (JS) scripts, requiring the browser to pass mathematical "challenges"... It was those scripts that were being "racist" towards non-mainstream browsers and thus those browsers (including the UXP ones) were outright denied access to sites CF intend to "protect" from "unwelcome" traffic... That CF issue (please search this thread for more details) finally made it to prominent web sites/forums, not to mention the "loud voices" of some Pale Moon users (to which we owe big thanks ) on CF's Community Forums, so it had to be acknowledged and acted upon by real CF devs... It was "them" who fixed it for us (but some more "obscure" web browsers, like the Qt-based Otter Browser, are reported to still suffer from this "racism" ) ... OT: @Dave-H : Do you, hopefully, know what happened to https://thedndsanctuary.eu/ that used to post invaluable info about the Otter Browser ?

... issue persists with latest v1.367.457.0:

WD x64 definitions, version 1.367.386.0 (engine version 1.1.19200.6): https://definitionupdates.microsoft.com/download/DefinitionUpdates/VersionedSignatures/AM/1.367.386.0/1.1.19200.6/amd64/mpas-fe.exe WD x64 definitions, latest version: https://definitionupdates.microsoft.com/download/DefinitionUpdates/amd64/mpas-fe.exe BTW, I need some feedback from Windows Vista SP2 users (x86 and/or x64) running the nag-free version (4.4.304.0) of Microsoft Security Essentials: Are you able to update MSE's defs past v1.367.386.0 without MSE's Windows service crashing? Manual download links: https://definitionupdates.microsoft.com/download/DefinitionUpdates/x86/mpam-fe.exe https://definitionupdates.microsoft.com/download/DefinitionUpdates/amd64/mpam-fe.exe

Well, it looks like Microsoft have managed to kill Vista's native antispyware, Windows Defender (not to be confused with Microsoft Defender Antivirus for Windows 8.1+) for good , either inadvertently or deliberately... I won't be discussing the "merits" (or lack of...) of WD as a proper ASW solution, but I still have its real protection ON, along with my third party Security Suite, and have it scheduled to perform a "Quick Scan" every night at 23:00 (in my timezone). For those not following this, MS have, since long ago, stopped issuing WD definition updates via Windows Update, those were used to be called "Definition Update for Windows Defender Antivirus (!) - KB915597" and the last one on this machine (v1.297.531.0) was received and installed on July 6th 2019: A few days later in that July, Vista SP2 was severed from the WU servers , due to the SHA-2 implementation in those endpoints... It is unknown to me when exactly MS stopped altogether the production and distribution of the KB915597 updates (they're no longer to be found in the MUC either, unlike the KB2310138 ones, which are definition updates for Microsoft Security Essentials, still offered via MU on supported platforms - namely Win7 SP1). But MS continued to offer these definition updates (for Win7 SP1 & WinVista SP2) as standalone mpas-fe.exe files, accessible from their "Microsoft Security Intelligence" portal - it used to be called otherwise in the past, but the old name eludes me now... For the x86 architecture, the DL link is: https://go.microsoft.com/fwlink/?LinkID=121721&clcid=0x409&arch=x86&eng=0.0.0.0&avdelta=0.0.0.0&asdelta=0.0.0.0&prod=925A3ACA-C353-458A-AC8D-A7E5EB378092 An alternative, more "user-friendly", link is: https://definitionupdates.microsoft.com/download/DefinitionUpdates/x86/mpas-fe.exe Running the downloaded "mpas-fe.exe" file would update WD's definitions/signatures in a matter of ca. 20s (YMMV). In mid-October 2019, the file, as well as its internal constituents, ceased being dual-signed and was henceforth only SHA-2 signed; in order to make the "updated" files install on Vista SP2, updates from WS2008SP2 were necessary, that backported SHA-2 file signature verification to Vista itself... Since that time, Microsoft goofed-up on several occasions, by issuing 1. a "mpas-fe.exe" file with SubSystem version 6.1, that wouldn't run under Vista/WS2008 (6.0) 2. internal components of said file (e.g. mpengine.dll, MpSigStub.exe) also with subsys version = 6.1, or 3. internal engine file (mpengine.dll) compiled to target Win7 SP1 as minimum OS, calling functions missing in Vista's kernel . HexEditing the infringing file(s) would invalidate their SHA-2 file signatures, making them not verify and not install... These "hiccups" were, one way or the other, reported to MS, especially by WS2008SP2 ESU paying customers, and they were eventually mitigated (within several hours or, more commonly, days). FWIW, I have the following batch file I run daily, to update my WD defs: @echo off start /min /wait cscript "create_restore_point.vbs" start /min /wait wget -S -N --unlink --secure-protocol=TLSv1_2 "https://definitionupdates.microsoft.com/download/DefinitionUpdates/x86/mpas-fe.exe" if exist mpas-fe.exe start /min /wait mpas-fe.exe The .vbs script (not posting it here, unless asked) creates a restore point prior to the update, while wget only downloads the file if it's newer (on the server) from the one previously fetched on disk... Come Tuesday May 24th, 2022 - file "mpas-fe.exe" is now at versions 1.367.3xx.0, engine is at version 1.1.19200.6, all looked fine, including version 1.367.386.0 (signed on 24/05/2022): https://definitionupdates.microsoft.com/download/DefinitionUpdates/VersionedSignatures/AM/1.367.386.0/1.1.19200.6/x86/mpas-fe.exe BTW, that direct link will expire soon (in a day, two at most...); with that version installed, WD is "happy", ... I even performed a "Quick Scan" to completion: But 1.367.386.0 was to be the last of the "3xx" series, then came the "4xx" ones: 1.367.413.0, 1.367.415.0, 1.367.423.0, 1.367.432.0 (latest at the time of writing), which did keep, however, the same engine version, 1.1.19200.6. Each one of these will cleanly install on top of 1.367.386.0, but won't install in the normal fashion on top of one of the previous "4xx" ones (e.g. 1.367.423.0 updating 1.367.413.0, etc.); in fact, installing any of these "4xx" ones on top of "386" will go fine initially, but after 20-30s WD will "crash", due to the WD service having stopped: If you try to perform a "Quick Scan" before WD crashes, you'll get a similar breakage: So, there's something inside files "mpasdlta.vdm" (the actual defs file) of the "4xx" series that makes the WD service crash under Windows Vista SP2 ... The release of that "1.367.4xx.0" series signals the death nail of WD under Vista, because it becomes unusable/non-updatable anymore... Mind you, returning WD to a working state, with 1.367.386.0 installed, wasn't an easy thing either (but I did it), as running file mpas-fe.exe (of that version) doesn't cut it... But I probably shouldn't go into specifics, because, in reality, it's a moot point: in 2-3 days' time, WD will nag me about "out-of-date signatures", however, if things haven't been changed by MS (I don't expect them to be ...), the route to update those signatures won't be "enforceable"... Thanks Microsoft, once more ... In all honesty though, I'd have expected them to end WD support in Jan 2023, same time the Win7 SP1+WS2008 SP2 ESU plans end, so am not fully convinced they had a mind to prematurely kill it on Vista... The amount of WD users on WS2008SP2 is probably zero now, so news of this will likely never reach MS staff... To quote "The Doors":

The actual reason that "popout chat" won't load in Fx ESR 52.9.1 is that Twitch are now using the ResizeObserver API there: That API was first implemented in Firefox 69.0/Google Chrome 64.0, so am afraid the use of ProxHTTPSProxy together with FxESR 52 will do nothing to mitigate your "Twitch chat" predicament (as the problem isn't really secure-protocol and/or cipher-suite related) ... Since the missing API I mentioned above was first implemented in Ch64, ALL three versions of 360EE, v11 (ch69-based), v12 (ch78-based) and v13 (ch86-based) should be able to display that Twitch chat... OTOH, MyPal68 is based on FxESR 68, thus shouldn't be able to handle it... Good news is that the UXP browsers (e.g. New Moon 28, Serpent 52.9.0) have that API now natively implemented, so they should be also fine for your usercase: (this one is with Serpent 52.9.0 ; BTW, I don't have a Twitch account...)

The 1s, video-only, clip (GIFV) in the tweet below: https://twitter.com/KeviSkillz/status/1527748243001581571 refuses to play in Serpent 52.9.0 32-bit: I tried first with Vista SP2's native h264 decoder, media.wmf.enabled;true media.ffvpx.enabled;false then with St52's "embedded" h264 decoder, media.wmf.enabled;false media.ffvpx.enabled;true and then with BOTH turned on, but still no dice... The direct link to the clip is: https://video.twimg.com/tweet_video/FTOm21xX0AcJkcs.mp4 and when that is loaded in a tab, it too, as you'd expect, fails to play, citing: "Video format or MIME type is not supported"; perhaps UXP's MP4 parser and/or the (ffmpeg-based) h264 decoder of St52 (inside the ffvpx lib) is in need of an update/fix... "naturally", 360EE has no problem playing back that embedded clip...

@roytam1 : Success indeed! : File "./basilisk/omni.ja" was de-optimised and unpacked (with 7-zip) to omni dir; compiled file "./omni/jsloader/resource/gre/modules/GMPUtils.jsm" was DELETED; source file "./omni/modules/GMPUtils.jsm" was edited according to the "fix"; contents of omni dir were compressed back to an omni.ja (zip) archive; modified omni.ja file was optimised and put in the place of the original (that came with the 2022-05-12 release).

Many thanks, indeed... ; that commit's title is: "GMP: revert GMPUtils.jsm back to state of rev 4a010b9"; looking more closely at the "History" of changes of involved source file GMPUtils.jsm, https://github.com/roytam1/UXP/commits/ed4e67920f81c1578a875925efb20188a2281a33/toolkit/mozapps/extensions/GMPUtils.jsm I can see that the recent breakage was due to "Issue #1829 - Revert "Issue #1751"", a huge squashed-commit by Mac dev @dbsoft (who was again invited back into the team of upstream devs, after M.A.T's exit...), that made it to Serpent 52.9.0 (2022-05-06) release; FWIW, I don't get why "we" are also reinstating Mac compatibility/build-ability in "our" (i.e roytam1's) UXP tree, but this is obviously NOT my call... I can also see that the last working ("good") iteration of file GMPUtils.jsm was/is https://github.com/roytam1/UXP/commit/d4582b821c97d11f016d7ab8dcc3a380dcabc6fa from back in May 7th 2021, commit d4582b8, but the "new fix" references commit 4a010b9 (Mar 19th 2021) that didn't modify that file ; perhaps I'm missing something here... In any case, I'll be sure to test coming Saturday's Serpent 52 new release, to verify all aspects of the regression I reported are mitigated... Many thanks again for your attention to users' reports, always keep a watchful eye on code imported from upstream ... Best regards and wishes!

... I wish I could say the same here (Vista SP2 32-bit) , however I was bitten by a new regression that started with Serpent v52.9.0 (2022-05-06) (32-bit) ; if you're on WinXP, that one would not be of much impact to you (unless you're using Adobe Primetime CDM as a h264/aac decoder), but if you're using St52 on Vista SP2/Win7 SP1 (or higher...), do stay with me... (If you're not interested in the analysis below about EME/DRM and GMPs in Serpent 52, skip that and head to "The regression itself" section) First, a "record" of things, well, sort of... As you probably know already, upstream (MCP) harbour an ideological aversion for EME (Encrypted Media Extensions, used in the context of in-browser DRM), as such official Pale Moon never supported it! OTOH, when they created official Basilisk (among other things, to attract "legacy" FxESR52 refugees), they decided to let it stay there, in the state it was inherited from their "upstream", FxESR 52.6.0 . EME in the browser entails the installation of two third party DRM plugins, correctly called CDMs (Content Decryption Modules): 1. Adobe Primetime CDM 2. Google Widevine CDM The first was quickly obsoleted in favour of Google's one, in fact WV is the sole in-browser CDM used today in desktop browsers to decrypt DRM content... Unlike AP, which came with its own patented decoders, WV on a Firefox-type browser relies on OS decoders accessible via WMF (Windows Media Foundation), a Windows feature to be found in fully updated Vista SP2 and higher (i.e., not WinXP) ... Google issue frequent updates to their WV CDM, usually to combat discovered and exploited vulnerabilities, but also to remove support for OSes and devices they no longer consider kosher , in essence dictating the type of device and client (browser) you can view their DRM'd streams... The WV CDM is heavily intertwined into the browser's EME implementation, a said Fx version (especially the non-Quantum ones) can only accommodate a specific WV version; FxESR 52 originally came with support for WV v1.4.8.903; when that one was deprecated, MCP tried and managed to equip Basilisk with support for later WV versions, but their effort was forced to stop on (what would turn out to be) final support for WV v1.4.9.1088 ; UXP proved practically "incompatible" with later WV versions (4.9.*, 4.10.*); that very same support has been ported to Serpent 52.9.0 and was present until v52.9.0 (2022-04-29) . WV v1.4.9.1088 was deprecated on Aug 14th 2019, since then St52 can't decrypt DRM content when used in Vista SP2/Win7 SP1 ; FWIW, the latest WV version is v4.10.2449.0, the CDM's dll requires Win7 SP1 or higher, Chrome 69 or higher, FxESR 91 or higher... While St52's WV support is now "broken" for decrypting purposes, I still regard it as "working" for, at least, correctly identifying the browser is requested to play back a DRM'd stream; once so, I can then seek playback on another supported device in my household (Win7 and/or Win10 laptops); e.g. when loading the DRM test case by bitmovin in St52 (2022-04-29), I get this: i.e. the WV CDM is correctly picked up by the site, and the DRM indicator is displayed in the URL bar, to the left of the padlock; as said, content can't be decrypted, the old CDM has been deprecated and the WV lic servers have blacklisted it... Unable to progress further in this field, MCP let Basilisk's DRM support rot away, but the official stance from them is Google's refusal to grant "margin" browsers the rights to use their CDM (well, this is true, but you get my drift ) ... Thus, upstream no longer check/care for/cater to EME/DRM support in their UXP tree, more so after officially declaring Basilsk as EoL a few days ago... Another technology MCP feel opposed to is WebRTC (never supported by them in PM), but they also left it in in official Basilisk; in the context of WebRTC, Serpent 52 downloads and installs the "OpenH264 Video Codec provided by Cisco Systems, Inc" plugin, at version 1.7.1; as indicated by MCP, WebRTC support is also to vanish from within their UXP tree... The two EME CDMs and the Cisco plugin (not a CDM) are referred to collectively as GMPs (Gecko Media Plugins). Disclaimer: When I set out to write up posts like this one, I intend them to serve as sort of Knowledge Bases, "there" even for future reference (as long as MSFN is up) by any interested party, even outside of MSFN; I'm fully aware though, that the length of such posts of mine doesn't bode well with the attention lifespan of many co-members/forum readers, I apologise to them, but they are always free to skip content... The regression itself Starting with Serpent 52.9.0 (2022-05-06), support for ALL GMPs has been completely BROKEN - this includes both the two CDMs (Adobe Primetime, Google Widevine) and the Cisco Video Codec ; I was still on a (2022-04-29) profile myself, when I decided to jump directly on to latest St52 build, (2022-05-12); I did not become aware of the breakage right away, but only when I tried loading a certain DRM stream (the one I troubleshot in my recent MSFN post here) and witnessed the browser acting "odd": the DRM indicator never came up in the URL bar, while it did so in FxESR 52.9.1... Additional troubleshooting revealed in fact that the DRM "breakage" started with the previous St52 release, (2022-05-06) ... STR (OS to be used is Vista SP2 - fully updated to EoS - and higher, XP is NOT suitable!) 1. Launch a new fresh profile of St52 (2022-04-29) (32-bit), package name is "basilisk52-g4.8.win32-git-20220430-3219d2d-uxp-cf4e046f9-xpmod.7z" 2. Load "about:preferences#content"; you should see the "DRM content" section; tick the "Play DRM content" box: 3. Give it 2-5min (YMMV), then load "about:addons => plugins"; you should see entries there for ALL 3 GMPs; NB: The AP CDM won't be auto-installed "shortly", actually, as the old (internal) download link is no more valid; there's a way to manually install if you have an archived copy of the CDM, but the process is beyond the scope of this bug report... 4. Exit the browser 5. Update the browser to Serpent 52.9.0 (2022-05-06) (32-bit), package name is "basilisk52-g4.8.win32-git-20220507-3219d2d-uxp-e207b5a16-xpmod.7z" 6. Launch the browser, it will use by default the previously created profile (by v2022-04-29) 7. Navigate to "about:addons => plugins"; you'll witness that ALL previous entries of the 3 GMPs have vanished: 8. In a quasi-similar test, delete the existing St52 test profile (with browser closed) and relaunch Serpent 52.9.0 (2022-05-06) (32-bit); a new fresh profile will be created. 9. In that fresh profile, repeat step [2]; when, afterwards, you repeat step [3], no sign of the 3 GMPs inside the plugin manager... 10. The next (latest) St52 release, Serpent 52.9.0 (2022-05-12) (32-bit), package name basilisk52-g4.8.win32-git-20220514-3219d2d-uxp-774750839-xpmod.7z, exhibits the exact same behaviour, i.e. no GMPs are either picked up from an existing profile nor installed in a fresh one: Regression range between 2022-04-29 (last GOOD) and 2022-05-06 (first BAD): https://github.com/roytam1/UXP/compare/cf4e046...e207b5a (I do see a reference to "gmp" here , but that commit made it to the (2022-05-12) build, also broken... ) Dear @roytam1, no doubt this is all caused by an "upstream" cock-up , do you think you can restore GMP (and, specifically, WV) support back into Serpent 52? Partial/"broken" as it might be in the (2022-04-29) build, I do have use for it... Currently back to the St52 (2022-04-29) release, which, sadly, misses the (?.) upstream implementation... Many thanks in advance ...

Yes, for latest UXP builds it's a transcript from: https://github.com/roytam1/UXP/compare/e207b5a...7747508 Code imported from "upstream" issues has the corresponding issue number clearly indicated, e.g. "Issue #1509 - Invalidate previous result when datalist is changed." One can find more details regarding that issue (and the "bugs" it potentially fixes... or not ) by looking it up in the upstream issue tracker, e.g. https://repo.palemoon.org/MoonchildProductions/UXP/issues/1509 Obviously, much of this is "Greek" () to most, non-coder, users, but surely "big" things, like support for optional chaining operator (?.), are cleary marked ; all one needs do is simply "comb" that commit log for resolved bugs that would positively affect one's own worklow... FWIW/OTOH, even Mozilla go into the trouble (?) of composing some form of "Release Notes" for their Firefox Nightly "trunk" builds (updated twice over the course of 24h) in, what @Mathwiz called, a plain-language "executive summary" of changes, e.g. https://www.mozilla.org/en-US/firefox/100.0a1/releasenotes/ with the "disclaimer": ; a separate set of "Release Notes" is also available for pure developers/coders: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/100

Well, posting some actual URLs would've helped... A quick G-search yielded the following "MyWater" site, where AW customers should log-in to pay online their water bill(s): https://www.amwater.com/caaw/customer-service-billing/billing-payment-info/ => https://login.amwater.com/ Putting-in FAKE UserID+Password, using 360EEv12, simply generates the "Invalid User ID or Password" error for me... ... Or is it, perhaps, this URL: https://ipn.paymentus.com/rotp/awk you're using yourself?

Well, each Saturday's releases do come with a changelog (Release Notes): Trust me, I'm with you on that and really feel your pain ... But, you'd have to isolate the very exact reason(s) your "American Water" site refuses to work in UXP browsers and Chromium<86-derived ones... From past recollections of your previous posts on the subject, it would appear the culprit A.W. script(s) come into play once you sign-in to that site, thus, as you realise, making it very hard for anybody else without an account there to troubleshoot this further... Warmest (30 C currently, already...) greetings!

@EarlyRizer: First, welcome to these forums ... Second, I hate to be telling you this, but there's practically nothing you can do under XP to mitigate this... CTV.ca are using Digital Rights Management (DRM) now on the streams found under https://www.ctvnews.ca/ctv-national-news I don't know how savvy you are, but these are MPEG-DASH streams with Common Encryption (cenc), for successful playback in a browser you need a very recent version of a browser supporting the very recent version of the Widevine CDM, the Content Decryption Module owned and supplied by the omnipresent "villain" Google; the latest widevine version is 4.10.2449.0 ; WV is closed source (as you'd imagine), plus support for XP+Vista was dropped many years ago... Your current options now include: 1. Watch the national news on your smart phone (Android 7+) or smart TV; you may need to install CTV.ca's DRM'ed app... 2. Resort to another desktop machine with, at minimum, Windows 7 SP1 (fully updated), on which the latest Google Chrome and/or latest Mozilla Firefox can run (these two will come with a sanctioned WV version) 3. Use your existing XP x64 OS (provided you have ample RAM there) to install and deploy a VM of a Windows (or other) OS capable of running those recent browsers mentioned in #2. Both FxESR 52 as well as SlimJet 10 come with "ancient" WV versions, long ago deprecated by Google, and thus can't acquire decryption licences/keys from Widevine licence servers... To add insult to injury, FxESR 52 under XP doesn't support WV at all, because WV (on Firefox) itelf relies on Windows Media Foundation, a feature not found in XP... The "Error Code: 102630" is generated form the embedded JW HTML5 player, more below: https://developer.jwplayer.com/jwplayer/docs/jw8-player-errors-reference#empty-playlist But in my case (Vista SP2 x86 fully updated), when using FxESR 52.9.1 to try and play the vid, I am prompted to enable DRM: but even if I do, no dice again: I get a different error ; FxESR 52 only supports (Vista and higher) Widevine v1.4.8.903, a version blacklisted by WV lic servers eons ago... Do you get the broader picture? Google, with their tight grip on everything web-related, have their sure way of crushing all users of OSes/browsers they don't saction themselves... PS: You can (still) playback vids over at https://calgary.ctvnews.ca/video because these are NOT DRM'ed (yet?)...

FWIW, if you switch back to last weekend's New Moon 28, it should work, too... https://forums.mst3k.com/ , as do most of newer sites, is tailored to work best in recent Chrome (and derivatives)/Firefox ; for the techie specifics, they're using the Optional Chaining Oprerator ("?."), part of ECMAScript2020 (a Javascript standard); by a "stroke of luck", OCO was very recently implemented upstream and made its way into last WE's UXP browsers by Roytam1; these include latest Serpent 52.9.0 and latest New Moon 28.10.6a1; having still a NM28 build from "earlier this year" was/is the root of your issue with "forums.mst3k"... BTW, if you have any sort of leverage towards the admins of that site, you should ask them to look into providing better backwards compatibility with non-Chromium type browser engines, aka "legacy" browsers, like the UXP ones (official Pale Moon and forks, official Basilisk and forks), official SeaMonkey (and forks), etc.; more so, if you plan to be a paying customer of theirs but, at the same time, continue using browsers supporting your XP OS... Who knows, next week they'll start using Chrome 98+ specific web APIs, very unlikely to become supported "here" in a timely fashion, if ever... In such a case, your eventual request for help here will be futile, sadly ... If, OTOH, you're prepared to be using Google's latest spyware on M$'s latest spyware OS to watch your movies there (on mst3k), then case dismissed...

@roytam1 : Your latest screengrab above is from St52, but I believe @Mathwiz's issue is with St55 ...

This has been explained often times in the past, though I'm now plainly lazy to track down relevant MSFN posts... The gist of it is: H.264 (for video) and AAC (for audio) are patented decoders, inclusion of them into an app demands the app authors pay a handsome fee to the patent holders (currently the MPEG consortium). Google are big/wealthy enough to afford the fee and thus have included those decoders in their Google Chrome web browser; this is not the case for many of the rest of the Chromium-based browsers (e.g [Chrom]Opera, etc.) Mozilla couldn't afford including those patented decoders inside the Firefox browser core; instead, they shifted the onus on the operating system itself... Through the Windows Media Foundation (WMF) framework, Firefox can make use of the OS-provided copies of h.264/aac decoders for decoding HTLM5 video (audio) clips; Media Source Extensions, MSE, also comes into play here for the playback of fragmented (DASH/HLS) streams... The unfortunate thing for XP die-hards is that WMF is only supported on Windows Vista SP2 and onwards - in the case of Vista, a slightly less complete (to the one in Win7) implementation of WMF is installed via Platform Update Supplement (PUS), itself a Windows Update offering... And I can tell you that "native" H.264 support in Fx came long before v53.0 (but only available, as explained, in Vista SP2+, not XP)... Roytam1 browsers on WinXP: The FxESR 45 fork and the Goanna 3 (Tycho) based forks, i.e. New Moon 27+K-Meleon, have been modified to load the patented decoders from externally supplied (and manually installed in the application folder) LAV dlls (these are based on the open source FFmpeg project; XP-compatible versions of FFmpeg are used to compile those LAV dlls...). The UXP-based browsers (New Moon 28, Serpent 52 etc.) have been modified to load the patented decoders from a modded, internal, codec library called ffvpx; ffvpx is itself derived from FFmpeg, but in Firefox it normally only includes support for VPx and other non-patented decoders; the roytam1 version of this library has been patched to also include h264/aac support (via native FFmpeg decoders). Indeed, if you toggle the about:config pref media.ffvpx.enabled to false, said browsers lose h264/aac decoding capacity under XP... Serpent 55.0.0 => Same case as with Serpent 52 Feodor's new child MyPal68: I haven't been following its code development, feel free to visit the main code repository and discover how native h264/aac support under XP has been implemented; my educated guess is, again, via FFmpeg libs... FWIW, the Cisco Openh264 Video Codec plugin was provided in the context of WebRTC video-calls (it can both encode/decode the video stream), but it was limited to low video resolutions, only, and could not (to the best of my knowledge) be used as a full-fledged h264 decoder for general MP4/HTLM5 web clips (i.e. unlike the Adobe Primetime CDM's included decoder) ... NM28 is being compiled without WebRTC support (this is set from upstream, they NEVER supported WebRTC in Pale Moon), so no wonder the Cisco plugin is not installed by default there... And Serpent 52/55's WebRTC implementation is lagging very much behind the current Google-dictated specs, so much so that the majority of services requiring WebRTC today (2022) don't work in those browsers... OK, have you got a clearer picture now?

If you have a browser (i.e IE8, Chrome 49) configured to use ProxHTTPSProxyMII Rev3e, use that browser to visit https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html wait for ALL tests to complete (might take some time, YMMV) and then inspect the 1. Protocol Support 2. Protocol Features -> Protocols -> TLS 1.3 -> Yes or No ... sections of the test results...

Windows 7 (SP1), WS2008R2 (SP1) and WS2008 (SP2) are also supported: x86: https://www.catalog.update.microsoft.com/ScopedViewInline.aspx?updateid=f16201fc-37a1-4166-9060-0a37cf2e242c https://catalog.s.download.windowsupdate.com/d/msdownload/update/software/uprl/2022/04/windows-kb890830-v5.100_be43404f6d4e6b1ca11831948610a4d58e291374.exe x64: https://www.catalog.update.microsoft.com/ScopedViewInline.aspx?updateid=23a75426-87bc-4851-9c5e-65f4db341d80 https://catalog.s.download.windowsupdate.com/d/msdownload/update/software/uprl/2022/04/windows-kb890830-x64-v5.100_39ac11b44ee409bd2e92ab441f958815f9241ae1.exe As it's already widely known, Vista SP2 (both x86+x64) is NOT supported!

Well, things look gloomy, indeed... I've read the following CF support article: https://support.cloudflare.com/hc/en-us/articles/200170136#browser-support and they plainly state: The "non-interactive JS challenge" GitLab are sending, as part of their CloudFlare protection, is meant to work on only the major villains, i.e. Chrome and "buddies" ... That article was last modified a month ago, possibly the same time GL log-in became broken... And it would seem that User-Agent-Sniffin' does play a role, in the initial detection at least, according to: https://support.cloudflare.com/hc/en-us/articles/204191238-What-are-the-types-of-Threats-#bad-browser https://support.cloudflare.com/hc/en-us/articles/200170086-What-does-the-Browser-Integrity-Check-do- https://support.cloudflare.com/hc/en-us/articles/204191238-What-are-the-types-of-Threats-#browser-challenge Indeed, when I spoofed Serpent 52 (via an extension) in my copy of 360EEv12, it too became unable to display the GL sign-in page ; back to its default UA and the GL sign-in page becomes accessible again (as told already in my previous post) ! Conversely, when I spoof "Firefox 100.0" in Serpent 52, I'm probably being served a JS challenge that can only be solved/passed by Fx 100.0 (or whereabouts), poor old St52 simply goes belly up...

Dearest @XPerceniol ; my own stance is for people to stop meddling with "about:config" advanced settings, especially when not sure what they're about; there's a good reason why "general.warnOnAboutConfig" is by default set at "true" ; but this is just me getting grumpier as I grow older... The referenced pref is an old remnant from an era when yt were still using both Flash and HTML5 embedded players; more at this link ; for many years now, yt are exclusively using their HTML5 player, so the setting of that pref is currently moot: you'll always be served the HTML5 version of the embedded yt video... I briefly toggled the pref to false, just to humour you, no yt breakage encountered here... As for performance slowdowns, am afraid this is something you'll have to check on your own particular setup (H/W+S/W) ... Best greetings EDIT: @UCyborg beat me to it by mere seconds!

This has now been merged into the master branch of upstream-UXP: https://repo.palemoon.org/MoonchildProductions/UXP/commit/92b3def6a88f9ea15c9e51e22a57b667edea29c0 Hopefully, it will also arrive in this weekend's roytam1 builds (fingers-crossed it doesn't break other aspects of the browser ) ...

Add https://www.cloudflare.com to the long list of sites that end up loading a blank page (latest St52 32-bit); CF homepage produces several TypeErrors in the Web Console... But seriously, today I jumped into a real deal breaker for UXP-based browsers: GitLab; it is no longer possible to sign into an existing GitLab account on a UXP-based browser (plus some others, read below) ... To begin with, to even successfully load GL pages in a UXP browser you're in need of the gh-wc-polyfill extension (manually/forcibly) installed (GL break things ever so often , make sure you're on the latest beta/stable release - currently v1.2.19). As long as you're not logged-in, things appear OK... STR: 1. Load, as a guest, e.g., https://gitlab.com/cleanflash/installer/-/releases (happens to be one of my bookmarks ) 2. Click on the "Sign in / Register" button (far right, top header); GL will load https://gitlab.com/users/sign_in/ 3. This is the crucial step where things broke ; to verify you're not an automated bot trying to sign-in, GL are serving your client (browser) with a CloudFlare-based "challenge" that it has to pass successfully in order for the sign-in page to display: During the last week(s), that "challenge" has been "upped" and is no longer compatible with UXP browsers ; the browser goes into an infinite loop of those "5 seconds" redirection cycles, "frying" your CPU in the process , and never affords the GL sign-in page below: FxESR 52.9.0 and (latest) Serpent 55 behave similarly (to St52) on my Vista SP2 32-bit machine; but I also gained access to a Win7 SP1 64-bit laptop and can report that Fx 56/ FxESR 60.9.0 / FxESR 68.12.0 are also unable to generate the GL sign-in page there; however, and that's really no surprise, the latest Fx 100.0 (32-bit) passes the GL challenge with flying colors and displays the GL sign-in page in ca. 2 sec ... The "challenge" is probably "feature"-based, rather than "UA"-based, because I tried to spoof "working" Fx/Chrome versions in Serpent 52, sadly with no success ... Back to the Vista machine, I also tried 360EEv11/12; the former (v11, Chromium 69 based), does require 1 to 3 redirection cycles (ca. 5-15sec, YMMV), but eventually does pass the GL challenge and the sign-in page is shown ; the latter (v12, Chromium 78 based) passes the "challenge" more effortlessly and affords the GL log-in page very quickly (the screenshot above is with that browser) ; I then used my GitHub account credentials to successfully access my GL account in 360EEv12 (I did not bother checking v13, I'm certain it will, too, work OK ). Just as a POC, I then exported (via an extension) ALL GitLab cookies from 360EEv12 to a "cookies.txt" file (Netscape format) and subsequently imported them (via another "legacy" extension) into latest Serpent 52; and that is the only way (obviously impractical ) I could browse GL being logged-in with St52: If anyone knows of a way to make GL log-in work natively in latest St52, do come forth!

Many thanks indeed for taking the time to apply "git-bisect" in order to pinpoint the exact culprit... Thank you, too! So, the "bug" is really there in latest UXP, just masked behind the disabled (by default) serviceworkers pref... I can indeed confirm that latest St55 (2022-04-29) (32-bit) does not exhibit the reported bug once "dom.serviceWorkers.enabled" is set to false ! Now, the real question is: Is that still a genuine UXP bug or just a misconfiguration on "msfn.org"'s side? FWIW, I have sessionrestore enabled in all three flavours of 360EE (v11/12/13) and there all "msfn.org" tabs are session-restored successfully (I believe ServiceWorkers are enabled by default in Chromium browsers) ...

... These should be the other way round...