VistaLover

That last commit, ea6e33cd0, is nowhere to be found currently in: https://github.com/roytam1/basilisk55/commits/master Was it simply forgotten to be properly committed in the GitHub repo or was it never included in the latest builds? I attempted to load https://github.com/roytam1/basilisk55/compare/c952169...ea6e33c for a more detailed changelog between latest and previous builds (needed for a bug to be reported in a future post), only to be notified by GH that: "There isn’t anything to compare."

This one DOES NOT officially support NM28, only the official Pale Moon releases are... Excerpt from install.rdf file for latest version 1.11: <!-- Pale Moon --> <em:targetApplication> <Description> <em:id>{8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}</em:id> <em:minVersion>28.14.0</em:minVersion> <em:maxVersion>31.*</em:maxVersion> </Description> Even if force-installed (you'd have to lower minVersion to 28.10.6a1), v1.11 is not guaranteed to properly work with NM28, because it now selectively applies polyfills/workarounds based on Pale Moon's platform version value : ; sadly, NM28 does not follow PM's platform version numbering (for latest NM28, it's 4.8.5) ... Any other extension that used to install and self-update in palemoon-28.10.6a1.win32-git-20220528-d849524bd-uxp-0855ba43d-xpmod but does NOT in palemoon-28.10.6a1.win32-git-20220604-d849524bd-uxp-e8b114fe4-xpmod ?

... Which add-on and from what repository? FWIW, in the latest UXP releases, there's at least one commit imported from upstream that deals with extension updates: Issue #1909 - Guard against empty update manifest URL

While being logged in, load: https://msfn.org/board/attachments/ Tick the box in the far right on the attachments you want to delete, then click the trashcan icon; beware: can't be undone! Your original posts where the deleted attachments used to be in will now have empty placeholders (in the case of images...)

Sadly, no idea - as I've posted previously, I don't own a "Smart" device, so Android/iOS aren't able to "outsmart" me ... But I'm sure an online search will get you all the info... It will: Google Extends Chrome Support for Windows 7 Users They have already: Firefox DNS-over-HTTPS (DoH)

... That still requires access to a non-XP machine for the actual patching... BTW, the author of FlashPatch recommends "Windows 7 and above", however a fully updated WinVista SP2 + .NET Framework 4.6.x should also do the job : https://github.com/darktohka/FlashPatch/issues/24#issuecomment-1063519569 https://github.com/darktohka/FlashPatch/issues/24#issuecomment-1066203448

libstagefright fix by @roytam1, committed more than two days ago, as a response to a bug report by yours truly : libstagefright: relax ctts flags checking. libstagefright fix by Moonchild ("official" UXP), committed 21 hours ago: No issue - relax ctts flag checking in media/libstagefright MCP's code is almost identical... Conclusion/Question: Is Moonchild now following "roytam1/UXP" ?

I have a portable "installation" of 360EEv11 here, so it's not associated with the ".pdf" file extension, however, when I open a new tab there and drag-n-drop a local PDF file, it does render as expected: Visit "chrome://plugins" and verify BOTH "Chromium PDF Plugin" & "Chromium PDF Viewer" are "enabled" and "Always allowed to run":

... The "desktop" app does NOT, as it's electron-based... OTOH, I'm not sure about current support status of Git-For-Windows ; I have an old version here, "2.22.0.windows.1", that works OK on Vista SP2 32-bit: CLI version also available (using mintty terminal):

https://bonkersabouttech.com/what-is-a-tor-exit-node/

Coming to a "theater near you", even on Windows, starting with Google Chrome v103 : https://support.google.com/chrome/a/answer/7679408#winDNSdef Non-Enterprise ordinary users won't have the option to "disable", unless, of course, the "community" juggles something up...

Many thanks indeed for identifying the root cause of that "small annoyance" (I'm not that often on Twitter, anyway ...), congrats for managing to fix it, after all! However, it seems I "attract" Serpent bugs "like a moth to a flame", because I just bumped on a new regression I consider far more serious than the inability to play back a specific GIFV Twitter clip: Currently, Serpent 52's native (JS-based) PDF Viewer (pdf.js) is BROKEN . STR 1. Install latest Serpent 52 32-bit build; package filename: "basilisk52-g4.8.win32-git-20220521-3219d2d-uxp-1e871780f-xpmod.7z" 2. Launch a fresh, pristine, St52 profile 3. Load "about:preferences#applications"; you should be able to verify that the default action (handler) for PDF files is "Preview in Serpent": 4. Open a new tab and try to load the remote PDF file below: https://helpx.adobe.com/pdf/coldfusion2021-support-matrix.pdf Alternatively, drag-n-drop onto that new tab a locally saved PDF file 5. Expected Behaviour: The PDF file should be rendered in St52's native PDF viewer (pdf.js); actual result: An empty tab : I do understand ; time is also precious here, but to save you some precious time, I narrowed down a regression range: Last GOOD build: "basilisk52-g4.8.win32-git-20220423-f94c0da-uxp-059e35a46-xpmod.7z": First BAD build: "basilisk52-g4.8.win32-git-20220430-3219d2d-uxp-cf4e046f9-xpmod.7z": Hopefully, this can be identified and remedied in time for Saturday's UXP "releases" ...

Many thanks! I'd have expected an auto redirection to take place to the new hostname ("thedndsanctuary.eu" -> "dndsanctuary.eu"), but it's probably just me being "grumpy" ...

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?