VistaLover

... What aspects of the GitHub site have now become broken for you? I had restored the SSUAO feature in FxESR 52.9.1 in the way I posted about previously (manual insertion of two local *.js files in the main app directory), my override pref for github is: general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0 and at the time of this post (June 3rd, 2019, ca, 22:50 UTC) I see no obvious breakage in github.com; but it might also be a CDN issue, i.e. the changes may have been first rolled-out in the Americas and have not yet reached the Europe github mirrors... Time will soon tell... ( On a related note, I see no github.com breakage in both UXP forks (NM28, St52) )

uB0-legacy has just been updated to version 1.16.4.11; those without uB0 updater installed, should download and install manually: https://github.com/gorhill/uBlock/releases/tag/firefox-legacy-1.16.4.11 Also, latest NM28-compatible language-packs have been (recently) updated to v28.6.0_RC2 : https://github.com/JustOff/pale-moon-localization/releases/tag/28.6.0_RC2

Have you, by any chance, tried GreaseMonkey for Pale Moon : https://github.com/janekptacijarabaci/greasemonkey/releases/latest (file greasemonkey-3.31.4-pm_forkBranch.xpi) ? Personally, in Serpent 52.9.0 I'm using latest ViolentMonkey (2.10.5) as userscript manager (of the WE type, still supported in St52 - but not official Basilisk/UXP).

It's controlled by pref app.support.baseURL default value is http://www.palemoon.org/support/ When you choose "Help", the browser tries to load http://www.palemoon.org/support/firefox-help which then auto-redirects to http://www.palemoon.org/faq.shtml

+1 ; in fact, I am indifferent to the whole "rebranding" hullabaloo ; personally, I know very well where I first learned about the existence of the Pale Moon fork (yes, that's what it is), i.e. this very forum/thread, I know very well where the compiled builds are hosted and where to download them from, I am well aware of @roytam1's GitHub repositories and blog, so I'd have to be senile to direct myself to one of the upstream sites for official support (especially given the fact how rude/hostile people there are to "intruders" ); OTOH, taking into account how similar the code is between PM and the fork in question, I have every right - if I wish to do so - to visit the official Pale Moon forum as an unregistered user and seek help there by searching already posted content; and, provided I have access to working official binaries, I might post an issue in the official github tracker (given I already have a GitHub account) if a bug I discovered in NM is reproducible in official PM; I won't, of course, make any mention of the fork on a non-supported OS; NB that Moonchild doesn't like people "littering" his tracker before the reported "issue" has been first filtered in his forum, but that's his own problem... To conclude, that is how far I would approach the official support avenues... ... New-name giving and artwork? Fine, if you like to occupy yourself with what is devoid of real substance ; there, I said it... (DISCLAIMER: No offence meant to members about to - once again - inundate this thread with new candidate browser names )

Cheers , you've come pretty close to the resolution of the reported issue; in fact, it's "instagram #2" deja-vu: the type of Javascript code to be sent to the client (browser) by the player.pl video portal is being determined by UA-sniffing; their poorly written site (which, by the way, is infested with third party scripts ) does not like any of the three user-selectable UA strings (testing with New Moon 28.6.0a1) : Native: Mozilla/5.0 (Windows NT 6.0; rv:60.9) Goanna/4.2 PaleMoon/28.6.0a1 Gecko compat: Mozilla/5.0 (Windows NT 6.0; rv:60.9) Gecko/20100101 Goanna/4.2 PaleMoon/28.6.0a1 Firefox compat: Mozilla/5.0 (Windows NT 6.1; rv:60.9) Gecko/20100101 Goanna/4.2 Firefox/60.9 PaleMoon/28.6.0a1 The JS code sent with any of the above UA selections renders the SEZON buttons for the Odcinki series inoperable (non-clickable); further troubleshooting reveals that that's because UXP can't handle the Firefox Quantum 60.9-specific code it's being fed ; a pure Firefox ESR 52.9 SSUAO for player.pl will make the SEZON buttons operable again, but when you first load the site you'll get a prompt to upgrade to a more recent (and supported) browser brand/version; you can dismiss that prompt and, hopefully, proceed to view... However, I've found that to make those buttons work as expected but not get nagged at (for running an older, unsupported, browser), one should use the "Firefox compat" string modified to report a Fx 52.9 version: general.useragent.override.player.pl;Mozilla/5.0 (Windows NT 6.1; rv:52.9) Gecko/20100101 Goanna/4.2 Firefox/52.9 PaleMoon/28.6.0a1 @Seba21 Please understand that your problem site is specific to Polish speakers and that most of its media content is geo-fenced for non-Polish IPs ; so it's quite difficult for members here that don't understand Polish to navigate that site, troubleshoot it and offer advice/solutions Be that as it may, I believe your issues can be cured by creating (in either New Moon 28 or Serpent 52) a Site-Specific-User-Agent-Override (SSUAO) for player.pl ; that procedure has been explained numerous times in this and other threads: Load about:config in a tab, promise to be careful Right-click in an empty space and choose to create a new "string" preference - a pop-up will be displayed As name of the pref, input general.useragent.override.player.pl and click OK - second pop-up will be displayed As value of the pref, input Mozilla/5.0 (Windows NT 6.1; rv:52.9) Gecko/20100101 Goanna/4.2 Firefox/52.9 PaleMoon/28.6.0a1 and click OK Close the about:config tab Reload the player.pl tab ... you should then be able to use your SEZON buttons...

@TechnoRelic @roytam1 has absolutely NO CONTROL over the mentioned URI; http://www.palemoon.org/unofficial.shtml is hosted on the "www.palemoon.org" domain, which is owned by Moonchild Productions; as you said, a tab with that URI loaded is triggered after an unbranded Pale Moon build (New Moon in this case) has been successfully updated (app version change). Actually, what gets displayed in that post-upgrade tab is controlled by the value of pref: startup.homepage_override_url For official builds, value is (string): http://www.palemoon.org/firstrun.shtml and, as stated, for unofficial (unbranded) ones: http://www.palemoon.org/unofficial.shtml What you suggest implies @roytam1 setting up (and hosting) a dedicated webpage with the changes you proposed; this can be a "minimal effort" solution with just some text and links, more effort required if artwork is involved (background and foreground images, logos etc.); the link to that webpage should be then set as value of mentioned about:config pref... In any case, you obviously lean towards "proper" rebranding of New Moon; MCP already direct unbranded build users to so those "clueless" ones are already informed (still, all these who can't be arsed to read any disclaimer of any form will continue to "irritate" Moonchild and company even if a specialised post-upgrade page is set up ). Even if New Moon becomes fully rebranded to Goldie Locks (haven't decided whether to include the 3 bears or not ) with completely new artwork and redirections to non-MCP related support sites, I don't think MCP will be totally freed from the random Goldie Locks user landing on their forum/github tracker (and this is what seems to be the only one and poignant issue they have with the rest of us...); just look at what happens with MyPal and (to a lesser degree) Centaury...

Same version, run on Windows Vista SP2 x86: 9 (!) handshake failures... Grazie ; might have to do with me having Windows Taskbar placed on the far right of the screen (i.e. vertical, not the default which is horizontal and in the bottom) ...

... FWIW, v0.41b runs fine under Vista SP2 32-bit ; previous v0.39b checked against 100 hosts, this newer version checks against 200 ! (0 detections in my system ) ... Might be also worth to "communicate" the app's bugged GUI, at least in Vista : very elongated window, with no-way to resize, minimize and/or maximize...

The "advantages" of "more secure" and "signed" WE-API based Firefox Quantum add-ons: https://www.ghacks.net/2019/05/29/another-malware-wave-hit-the-mozilla-firefox-extensions-store/ Relevant discussion in reddit: https://www.reddit.com/r/firefox/comments/buahte/a_wave_of_malware_addons_hit_the_mozilla_firefox/ Probably of lesser interest to us running still (?) Firefox ESR 52.9.x and/or Serpent 52.9.0/55.0.0, one has to wonder though...

... What is the actual meaning of this message? Will installing your way totally break Windows Update itself on the machine? If, OTOH, you mean that the installed version of .NET FW (> 4.6.1) won't receive any additional security & performance updates directly from WU, this is an already known limitation that applies even to 4.6.1 (which will install simply by running its default installer); only 4.6.0 is officially supported by Microsoft on Vista/Server 2008, as such is the last version that would receive updates the "normal" way; for any version higher than this, the user has to hunt down provided updates for 4.x.x in Microsoft Update Catalog, download and install manually... Also, have you tried a slight variant to your method? 1. First decompress the provided 4.6.2 official installer with 7-zip, as detailed previously in the "Last versions of software for Windows Vista and Windows Server 2008" thread. 2. In the created directory, locate file ParameterInfo.xml, patch as instructed and save the modifications (perhaps one other possible workaround could be to overwrite the original file with the one provided inside 4.6.2 Preview; the "Preview" does install normally in Vista). 3. Then, instead of running the .MSI file (as instructed in the mentioned thread), just run the Setup.exe file; it should read the modified ParameterInfo.xml file adjacent to it, allowing for a successful installation... ... Do you actually mean netfx_Full_x64.msi in the decompressed installer directory (NB, this is for Vista SP2 64-bit, only!) ? At least one person has reported some problems with 4.6.2 Final when installed via the ".MSI" method: My response: Presumably, @Win2000Fan's method simulates better a "proper" install as if original 4.6.2 installer (NDP462-KB3151800-x86-x64-AllOS-ENU.exe) had been Vista compatible from the start...

... Thanks, but as I already explained in detail, this is indeed the default setting, but has no practical effect under Windows XP; wouldn't matter whether it be true (the default) OR false, since XP doesn't have WMF... Many thanks, too ; as feared, this appears to be a limitation/bug in the way Vista's native h264 decoder handles the 9:16 video stream... Such is life

OK, follow-up : @Tangy: Many thanks indeed for your tests on NM28, St52 and FxESR52; the fact the clip played back fine in these browsers on XP provided additional clues for me (see below...). I am on Windows Vista SP2 32-bit myself, with Platform Update Supplement installed correctly; this means I have a working implementation of Windows Media Foundation (WMF) media framework, which, in layman's terms, means compatible browsers (Firefox and forks) have access to system (OS) decoders for patented formats (h264 for video, aac & heaac for audio); to be more precise, h264 decoding in HTML5 videos is delegated under Vista SP2 to system file mfh264dec.dll (file version on my setup is 7.0.6002.18392, "7" indicates this was a Win7 feature backported via PUS to Vista SP2). In Firefox ESR 52.9.0 under Vista SP2 (with PUS) I don't have to install and enable the Adobe PrimetimeCDM to achieve h264 decoding in HTML5 video (which is the case for WinXP), because the browser, as explained above, has direct access to OS decoders; this works 99% of the time, but, apparently, NOT for this specific video . In Media Source Extensions (MSE) capable browsers, Facebook serves the video via MPEG-DASH streams (fragmented .mp4 files); it is my conviction, after extended testing, that the default system h264 decoder can't cope with this video's unorthodox dimensions (being in "portrait" rather than "landscape" form, 9:16 instead of 16:9). If in FxESR 52.9.x I disable WMF by toggling media.wmf.enabled to false (and with no AP CDM present), then the browser has no way to decode the video stream; fortunately, facebook can still fall back to using the Adobe Flash Player NPAPI plugin (v32.0.0.171) for playback purposes and this does play the clip in question (but in a pop-up, not in-page): The situation is a bit different in the case of the UXP forks; to cater to WinXP users who, as stated, have no access to OS decoders via WMF, @roytam1 has patched the ffvpx library to include (ffmpeg provided) patented decoders for h264/aac; in Vista+, both following prefs are set to true by default: media.wmf.enabled;true media.ffvpx.enabled;true but priority is given to the WMF decoders; that is why I can't play back properly the mentioned video clip in either NM28/St52 (screengrab is with NM28) : If I toggle media.wmf.enabled to false, then h264 decoding is being delegated to the native ffvpx (ffmpeg decoders) implementation and, as things stand, can properly decode the "portrait" video (NM28): And, as expected, if I toggle both cited prefs to false, NM28 will use Flash (in a pop-up): ... Before I classify this as an obscure Vista bug (with no hope of ever getting fixed), I need to know the results of some additional tests: Many thanks for your time spent, especially during "office hours" ; but don't bother testing on WinXP, according to my troubleshooting and @Tangy's feedback, it will certainly work when ffvpx is the decoding module ... When given the chance, can you please re-test with media.ffvpx.enabled;false ? If it plays, then Win10's system decoders can handle OK the 9:16 h264 video stream... Lastly, I need some kind soul to test for me how latest New Moon 28.6.0a1 on Win7 performs on this clip when, again, media.ffvpx.enabled;false and media.wmf.enabled;true ; if it doesn't play, repeat the test with an official Pale Moon binary (ffvpx there doesn't have h264 decoding support); in the small chance the video doesn't play, it's a UXP bug on Win7 (which means it could be reported to the official devs and, down the road, be fixed eventually...); if the clip plays fine with only Win7's system decoders, it's definitive: my case is a fatal Vista bug I'll have to live with Many thanks for the attention and precious time of this forum's fine members PS: As to the mystery why the video plays back fine in NM 27.9.6 on my Vista setup, I think the answer coincides with my findings so far: facebook serves MPEG-DASH, this requires MSE; on Roy's Tycho fork, MSE+h264 decoding is handled by the supplied LAV dlls, not by the system decoder (as proven by a "youtube.com/html5" test without those files...).

I personally avoid Facebook like the plague, but, via e-mail, I was recently given a link to a specific facebook video (two orphaned bear cubs being given milk): https://www.facebook.com/arcturosgr/videos/2355323964725837/UzpfSTU2MzI1NjMwNjoxMDE1NTgyNzQ4OTUzNjMwNw/ I had latest Serpent 52.9.0 32-bit open at the time I received the e-mail but when I tried to watch the linked video (without loggin' in to facebook - I have no account with them, thank God! ), the page and the embedded player would load OK, however, as soon as I pressed the play button, I would only get sound but no video (player turns to black ). I decided to investigate and the other UXP-based browser (latest New Moon 28.6.0a1 32-bit) as well as Serpent 55.0.0/moebius and Firefox ESR 52.9.1 all three exhibit the exact same behaviour, i.e. the video stream isn't displayed! Browser Console in St52 gets populated with many Type, Syntax and Reference Errors... To my great surprise, New Moon 27.9.6/Tycho would play that specific facebook video fine! Both New Moon 27/Tycho and New Moon 28/UXP have by default the same SSUAO for facebook: general.useragent.override.facebook.com;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:99.9) Gecko/20100101 Firefox/99.9 (Pale Moon) so the difference between them should not be UA related... What did not come as a surprise, of course, was the fact that Google Chrome (49.0.2623.112, 50.0.2661.102, 51.0.2679.0) also played that facebook video fine (it's no secret that, in recent years, the web is tailored to suit mainly Chrome and not the other way round; especially when Google's own devs dictate themselves how the web should be; but this is a discussion for another forum... ). The person who sent me the video link was using Firefox Quantum 67.0 on Win7 SP1 and she could watch the video on her setup without issue; so, this appears to be a bug afflicting pre-Quantum Firefox versions and, to what concerns us XP+Vista users, the UXP platform... I took the extra step of creating a new clean St52 profile and even trying Safe Mode there, but the issue persists ; @roytam1 can you replicate and if yes, any insight/solution offered? In the meantime, I used youtube-dl to fetch the clip to disk, the resulting MP4 file has a Display Aspect Ratio (DAR) of 9:16, which is non-standard; perhaps this is somehow relevant?

... I don't think that @roytam1 has taken steps to change minimum system requirements for his FirefoxESR 45.9.x builds - the main purpose for the release of these builds is that 45 ESR is the last Firefox ESR version to run on (maximum) SSE CPUs . As with any ESR branch build, it has the same System Requirements as its stable (release) branch counterpart: https://www.mozilla.org/en-US/firefox/45.0/system-requirements/ https://www.mozilla.org/en-US/firefox/45.0esr/system-requirements/ So, if standard XP 32-bit is being discussed here, SP2 is mandatory! AFAICT, the last Firefox ESR that would run on XP x86 SP1 is v10.0.x (10.0.12esr the last to be released); the last stable release to run on that configuration was v12.0: https://www.computerworld.com/article/2502032/mozilla-sets-end-of-firefox-for-win2k--early-xp.html

"xpmodsse" is meant for people on older CPUs which only support the SSE instruction set (not SSE2 or higher...). Just "xpmod" is a more generic build for relatively newer CPUs that do support at least SSE2; and, though you didn't ask, the ia32 builds are for even older CPUs that have no SSE support at all... https://en.wikipedia.org/wiki/SSE2 https://www.mathworks.com/matlabcentral/answers/93455-what-is-the-sse2-instruction-set-how-can-i-check-to-see-if-my-processor-supports-it NB: UXP browsers (NM28, Serpent 52.9.0) as well as Serpent 55.0.0 require a minimum of SSE2

... Many thanks for this new set of updated UXP browser builds ; but... https://github.com/roytam1/UXP/commits/master appears to have been synced with official upstream prior to compilation of updated builds (e.g. 9843f04 pushes code identical to upstream 315ffd5 ), however the custom branch that you mention in your post, https://github.com/roytam1/UXP/commits/custom doesn't reflect the changes present in the master branch and hasn't been updated to contain the "May 24, 2019" code ; is this a simple omission on your part or something else ? Yes, this is c72afc3...315ffd5 ; but, as you said, this is only the official UXP changelog; it was your habit to include in the end of your post your personal/custom changes on top of the official changelog; I suspect the latest builds do include custom changes, especially because you announced so in another thread: and, if I'm not mistaken, part of these custom changes should be the ones included in: https://github.com/roytam1/UXP/commit/11ce2e0 ... but you haven't made any mention of those (?); please be kind enough and explain how things stand (?) ; and excuse me for being pedantic , but I (usually) do study GitHub changelogs and do compare the official one to your custom one; I probably belong to a very small (and, dare I say, "perverse") minority, but I can't help it... As always, huge thanks to you

... And while you were at it, you could have also used a slightly modified id string for Tab Tally 1.3.0 (or 1.2.0 etc.) for it to install in either Serpent 55.0.0 or Serpent 52.9.0: }, "applications": { "gecko": { "id": "@tab-tally-st" } } St55 still contacts AMO to check for WE add-on updates, so, based on your settings, you'll be either upgraded automatically to v1.4.0 or be prompted to do so manually... St52 currently doesn't check AMO for WE updates (due to MCP implemented changes), but this can be partially or fully restored (search one of my previous posts in this thread for how-to-do it ). Installing Tab Tally with a different to the default extension id means you won't ever be offered any additional updates from AMO (and this is a known hack if one wants to stay at a specific version of an extension without having to disable extension updates in the browser)... ... and that is why you can also remove the whole META-INF directory!

Good morning! Is "PM27's XPIProvider and friends" what is referred to as TychoAM in the UXP GitHub repo? Was that change implemented early on in UXP development (I was under the impression WebExtAM was only removed towards the end of 2018/start of 2019, when WE support in Bk52 was obliterated )? From a comment by Moonchild himself exactly a year ago: https://forum.palemoon.org/viewtopic.php?p=141539#p141539 https://forum.palemoon.org/viewtopic.php?p=141641#p141641 Best regards

... I spent the better part of last hour researching and reading on this ; the ability to install id-less extensions from AMO into Basilisk was lost (what is called a regression) when the MCP devs decided to remove the internal platform mechanism that effectuated extension signature verification; this happened early on during Basilisk's development, when the (experimental at the time) application was "baking" on top of the (now deprecated) Moebius platform... Put very simply, id-less extensions acquire first a temporary (internal) id and then a permanent one, whose strings are derived from their verified signature hash; you need to have a working internal mechanism to process the add-on's signature and then generate valid id strings for the installation to succeed; but the devs in Moebius wanted to remove that mechanism altogether and not just allow the installation of unsigned extensions, because then unsigned installed extensions would produce warnings inside about:addons (Add-ons Manager, AOM); this is indeed what happens when you install unsigned extensions in FxESR 52 with the pref xpinstall.signatures.required set to false (NB that, as I have posted in another thread, extension signature verification - in FxESR 52 - is still performed in the background for already installed signed extensions and will also be triggered when a new signed extension is about to be installed!). There wasn't uniform agreement between the dev team which features inherited from Mozilla should be kept and what regressed functionality should be restored; Moonchild himself wanted to cut-off reliance on Mozilla-issued certificates (in hindsight, he was probably right, given the recent - May 3rd - armagaddon-2.0 Mozilla debacle), that meant removing the signature verification code; an "incomplete" workaround was implemented in PR #279 (see below); in any case, the focus of the team was always on Pale Moon (which, by design and choice, doesn't support WEs at all), as for Basilisk's inherited WE support, it wasn't very high on their agenda at the time (and we all know how that ended! ). If you've got spare time to spend, some Moebius era GitHub issues and pull requests are linked below: Addons - Can't install some addons: https://github.com/MoonchildProductions/moebius/issues/238 Add ID from a signature if it isn't included in manifest.json: https://github.com/MoonchildProductions/moebius/pull/251 Fix signed extension checks: https://github.com/MoonchildProductions/moebius/issues/277 (emphasis should be put on Moonchild's comment below: https://github.com/MoonchildProductions/moebius/issues/277#issuecomment-356231470 ) Get IDs for ID-less WebExtensions without breaking normal libJAR signature checking: https://github.com/MoonchildProductions/moebius/pull/279 Then the Moebius platform was left to rot... When Basilisk was later ported to UXP Take 2 (now just UXP), the issue of id-less WEs resurfaced: https://github.com/MoonchildProductions/UXP/issues/373 but Moonchild decreed: and he "WON'TFIX"-ed that issue... ; moot point now in the case of official Basilisk, still an issue with the Serpent 52 fork... =============================================== Disclaimer: Had a rough day today , so I might have not grasped 100% correctly what was contained inside the devs' exchanges in the linked issues/PRs; I have the sense the "general idea" is there, but anyone is free to correct any misunderstandings on my part...

... Let us just revisit Tab Tally, shall we? https://addons.mozilla.org/en-US/firefox/addon/tab-tally/versions/ All versions currently listed on AMO are, of course, of the WE format; version 1.0.0 is advertised as being compatible with Firefox 49.0+, versions 1.1.0 through to 1.3.0 advertised as being compatible with Firefox 48.0+; I was particularly interested in one of those older WE versions, because they duplicate the functionality of the XUL ("legacy") version 0.1.1, now removed from AMO (but is recoverable via the CAA extension). All (WE) Tab Tally versions 1.0.0 to 1.3.0 install and function properly in Firefox ESR 52.9.0[1] ; "properly" is actually the "desired-by-me" way (constant visual display of the number of tabs, updated in real time when that changes...); of course, the latest version 1.4.0 also installs there, but with a slightly degraded (IMHO) functionality... But trying to install any one of Tab Tally versions 1.0.0 to 1.3.0 in Serpent 52.9.0, you'll be met by a failure to install in the form of message: That's because v1.0.0 to 1.3.0 are id-less WEs (one only has to inspect their manifest.json files) and Serpent 52 lacks the API to allow installation of id-less WEs (but FxESR 52 does support that API). In version 1.4.0 of Tab Tally, the author re-introduced the "WE-id" feature inside the manifest.json file: "applications": { "gecko": { "id": "@tab-tally" } } and made it compatible with even older Firefox versions (min version lowered from 48.0 to 42.0) and, probably unbeknownst to him, also restored St52 compatibility; 1.4.0, as discussed previously in this thread, would install fine in St52 (but not v1.0.0-1.3.0, which do install and work fine under Firefox ESR 52.9.0... )

seems possible, will have a look later. This is most excellent news! Once again, really grateful for such stupendous support Addendum: Relevant GitHub commit: https://github.com/roytam1/UXP/commit/f4af0a7

A simple forum search could have easily taken you there :

Doesn't seem to matter though. I never claimed (or implied) that staying at NSS 3.44 Beta (instead or reverting to 3.43 Stable) would have allowed for the UXP browsers to successfully connect to the linked test server, i.e. https://tls13.1d.pw As I was already talking about the NSS library, I simply found an opportunity to mention the version downgrade I had observed; just that ... Today I borrowed briefly sister's Windows 7 SP1 64-bit laptop, where I updated stable Firefox (Quantum) to latest release 67.0 and Firefox ESR (Quantum) to latest release 60.7.0; to my great astonishment, both these Firefox versions connect successfully to the TLS 1.3 test server being discussed in this very thread; I dug around and found v60.7.0 comes with NSS 3.36.7, while v67.0 comes with NSS 3.43, the same one to be found inside the latest UXP forks released by Roy; so, despite my initial assessment, the "bug" observed here ("SSL_ERROR_RX_MALFORMED_SERVER_HELLO" error code when trying to connect to test server with latest New Moon 28/Serpent 52.9.0) doesn't appear to be only dependent on used NSS version and has been already fixed in latest Firefox Quantum releases! I persevered with my searches and, in the end, I stumbled upon a similar issue that was also affecting the Waterfox fork: https://github.com/MrAlex94/Waterfox/issues/783#issuecomment-458907249 So it looks as though the proper fix for this issue lies inside Bugzilla bug #1430268 fixed in mercurial commit: https://hg.mozilla.org/mozilla-central/rev/fafb731 @roytam1: Do you think you can somehow backport bug #1430268 to the UXP platform and thus apply it to both NM28/St52? Is a test-build even possible? If yes, then the OP (@Bersaglio) won't have to use a Chinese browser to connect with... OT: I don't mistrust myself the Chinese browsers any more than I do American ones like Google Chrome or Russian ones like Yandex Browser; all government security agencies are pretty much the same in my eyes... ; in this day and age, there's no such thing as privacy if you decide to connect to the live web...

... This doesn't add up; the New Moon 27 64-bit crash was first reported by @mockingbird in the following post: The crash was indeed due to module nss3.dll, but the reporter specifically mentioned package: https://o.rths.cf/palemoon/palemoon-27.9.6.win64-git-20190427-a09f31062-xpmod.7z as the one the crash occurs with... As you said, that build is the one where the NSS lib downgrade took place, https://github.com/roytam1/palemoon27/commit/a09a17de63be6e059e60559e15cca3448d362428 but still that 64-bit build would crash for the reporter... Furthermore, @roytam1's fix for that crash was announced here: soon after the 2019-05-10 New Moon 27.9.6 builds were announced; @mockingbird verified the fix: ... But looking at the posted changelog for these builds, I don't see a change in the NSS lib version, which I assume still remained at 3.43 (final), the same one inside the crashing build of 2019-04-27 ; am I missing something obvious here?