VistaLover

If that wasn't a rhetorical question... : https://design.firefox.com/photon/

... It was detailed in the official Pale Moon forums that UXP (off of Mozilla ESR 52.6.0) is the final Mozilla code fork-point for Moonchild Productions' applications, as they concluded that any more up-to-date Mozilla code is, in fact, incompatible with XUL apps and their own vision of how apps should be: To this day, they claim they'll stay clear of the Quantum platform (which includes Rust, Servo and other XP+Vista incompatible code/libs), so my gut feeling is if/when official Pale Moon 29.x.x is released, it'll be built on a UXP evolutionary off-spring (thus, still being susceptible to the XP+Vista restoration "treatment" ); of course, time will only tell

OS: Windows Vista SP2 32-bit Browser: Serpent v52.9.0 (2019-04-19) (32-bit) buildID=20190419233752 Original browser package: "basilisk52-g4.1.win32-git-20190420-51722cd4f-xpmod.7z" Userstyle manager extension installed: Stylem 2.2.4 Sadly, it well appears that installing userstyles directly from the userstyles.org repository is currently broken (again ) : Clicking the "Install Style" button gets the tab to become unresponsive/hang, with no prompt appearing to install the style... Is it 1. The site's fault? 2. The browser's fault? 3. The extension's fault? In any case, I had to use the workaround posted in this thread some months ago... about:addons => "User Styles" tab => "Install style from URL" button (second on top-left) => Input the following URL: https://userstyles.org/styles/144028/google-clean-dark.css

... The Moonchild Productions devs have just bumped appVersion to 28.5.0a2 in their master branch: https://github.com/MoonchildProductions/UXP/commit/bccf86a (bumping platformVersion as well to 4.2.0); I expect @roytam1 to soon follow on this - when that happens, your script will fail and'll have to be amended... Just a heads-up!

... Thanks for the heads-up; Vista SP2's build number change has been already reported: In fact, I do believe your post should've been originally submitted to that thread (Server 2008 Updates on Windows Vista), as the one here is marked "Last versions of software for Windows Vista and Windows Server 2008"; please submit any follow-up to that, more appropriate, Vista thread... I'd be keen to hear from other Vista users as well about eventual OS instability as a result of installing KB4493458 (but, please, in the dedicated thread I linked to...)

... Thanks ; your direct link fetches file sw_lic_full_installer.exe (12.5 MiB); same Adobe directory, but what I consider the more standard filename, Shockwave_Installer_Full.exe (14.4 MiB); probably a case of "pot-ayto/pot-uto" Happy Easter to you, den

... and with it came a revised Oracle Licensing Agreement: Oracle Technology Network License Agreement for Oracle Java SE As usual, I went directly to the Oracle download page to manually fetch latest installers for both 8u211 & 8u212: Java SE Runtime Environment 8 Downloads On Vista, both continue to work as intended; with every new JRE release, I would archive both and install either one (mostly the odd-numbered one...); latest release files were, up-until-now, publicly available, whereas the immediately previous and older releases, available via the Oracle Java archive, required an Oracle account ... While the latest, Windows 7+, 64-bit (only), compatible Java (JDK) offerings are still publicly available (i.e. accessible without an Oracle account), I, like @Dave-H, soon found out, to my substantial dismay , that the current/latest JRE 8u211/8u212 files are now behind a mandatory Oracle account! Then I had a read of the "Updated Licensing FAQs" over at https://www.oracle.com/technetwork/java/javase/overview/oracle-jdk-faqs.html from which I quote: ... Off to java.com I go, then... ; the problem with that download page is that, for Windows users at least, it only provides 32-bit (and 64-bit) installers, and only for the odd-numbered JRE version (8u211) ; this already constitutes a limitation for Windows XP SP3 users, for whom the provided installers don't function at all; XP users need access to jre-8u21x-windows-i586.tar.gz archives in order to update their installations... Also, in the Java Development Kit 8 Update Release Notes they mark both 8u211 and 8u212 versions as being (GA): "General Availability"; isn't that a distorted sense of the term "general", given that login-credentials are now required? If you don't want to create an account with Oracle, I found file jre-8u212-windows-i586.exe FREELY available over at FileHorse; just be careful not to download their proprietary downloader (2.6MiB) but the actual Java installer (66.4MiB - use the "if it doesn't click here to start it" page link ). For the .tar.gz archives, I'm afraid an account is needed (I'm not advising others to do the same , but I just visited this site and the first set of credentials there worked fine; for crying out loud, this is a free, "generally-available" file, so I don't feel shame in the slightest...).

... Using more than one content-blockers at the same time is inadvisable : https://github.com/gorhill/uBlock#note-for-all-browsers More is... less in this case; uBlock Origin and Adguard are both competent in what they do, so choose the one or the other (I use the - Russian made - Adguard solution in my Yandex Browser (17.6.0) copy and I find it can satisfactorily replace uB0 ). Just my two (euro)cents, of course...

... I still stand firmly by the advice I posted on this! For further reference, people should really read Moonchild's words on the matter: Can I copy my profile between Firefox/Pale Moon/Basilisk? Furthermore, things are not so "intimidating" as you make them sound; once you know what and how to selectively transfer from the old app's profile to the new browser profile, it's a matter of a few hours, possibly less on more simple profiles... Since we're talking about migrating profiles between Mozilla-type applications, the ample Firefox-oriented literature found on line is still valid/applicable (with certain modifications, of course): https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data https://support.mozilla.org/en-US/kb/back-and-restore-information-firefox-profiles https://support.mozilla.org/en-US/kb/recovering-important-data-from-an-old-profile http://kb.mozillazine.org/Transferring_data_to_a_new_profile_-_Firefox Bookmarks, browsing history (download history included in that), sessionstore, custom search engines, login-credentials for sites and cookies are easily transferred in a matter of minutes. Then give some time to configure the new browser's GUI to your liking; then some more time inside the browser's preferences tab/window to configure them accordingly (different browsers may - and do - have different settings...). I'll agree that the most cumbersome part is re-installing needed extensions; but: 1. Several extensions provide native support for exporting their settings to files (.txt/.json/.ini etc. ), which you can then use to reconfigure them exactly the old way in a new installation (e.g. Classic Theme Restorer, CookieKeeper, uBlock Origin, to name a few...). 2. Some legacy extensions store their settings inside the actual profile folder, in various guises; uB0 stores its filters inside the extension-data directory, as an .sqlite database - Stylish/Stylem userstyles are stored in the form of a stylish.sqlite database in the root of the profile - GreaseMonkey userscripts are stored inside a gm_scripts directory, and so on... So all these are easily transferable! 3. The bulk of legacy extensions store their settings as "about:config" preferences; but these are actually stored inside file "pref.js" in the root of the profile. Using a text editor, you can open file "pref.js" from the old (backed-up) profile and selectively transfer extension settings to the new "pref.js" file (inside the new profile - with browser closed, of course...). Speaking from past experience, I'd say the most elaborate profile migration for me was from official unstable Pale Moon 27.9.1a1 (on Tycho) to New Moon 28.0.0b2 (on UXP) by Roytam1; I did not migrate early on, because I wanted UXP's teething issues to be cured first ; the two platforms are oceans apart, so I opted for a "proper" transition; several old extensions had to be discarded for good, alternatives to be found, some had to be updated to later versions, etc. but it was all over in less than 3 hours... Some fine tuning was still needed during the week after the migration (e.g. I decided I had to quit trying to make FTDeepDark work and go for Dark Moon) but all-in-all I had the least of problems compared to people who chose the "easy" way out (and then sought help in the PM forums...). But of course, YMMV; if you took the quicker way and you're OK, so much the better!

One problem with Serpent55/Moebius is that it advertises itself on AMO as being Firefox 55.0, when the moebius platform in reality is much more akin to Mozilla 53.0; so AMO will offer the installation of extensions originally meant for Fx55 compatibility; browsing AMO can be mitigated by issuing a SSUAO for it: general.useragent.override.addons.mozilla.org;Mozilla/5.0 (Windows NT 6.1; rv:53.0) Gecko/20100101 Firefox/53.0 But Serpent internally still claims to be Firefox 55.0, so - if automatic addon update is enabled - may even update existing extensions to their Fx55 compatible versions, possibly breaking things, especially where the GUI aspects of the browser are concerned... Internal extension update mechanism (from AMO) is controlled (among others) by the following two prefs: extensions.update.background.url extensions.update.url In my own copy of St55, I edited the string %CURRENT_APP_VERSION% inside the value of both prefs to read 53.0. Both above "fixes" were more to-the-point when AMO also included legacy extensions; now they only apply to the few WEs there that are still Fx53+ compatible... One third, difficult to mitigate, issue is that Serpent 55 also reports itself as being Firefox 55 to individual extensions about to be installed/already installed. Some type of extensions have different internal code depending on the version (among the range of versions they support) of the browser they're installed in; so, if a certain addon has one set of internal code for Fx53 and another set of code (JS/CSS, etc.) for Fx55, when it is installed in Sepent55 the code for Fx55 will be active, whereas the "more" appropriate code would've been the one for Fx53. I encountered such an issue when I tried to install my favourite Complete Theme (FTDeepDark by Stefano Rosselli) on Serpent 55; while the Fx55 compatible version on AMO (back in the day...) was v14.4, after installation many parts of the browser GUI were broken ; then I downloaded and installed v14.3.1 (which AMO said was 53.0-55.0 compatible), but again, after installation, my problems were not rectified - the theme was internally applying the v55 CSS code, instead of the also present 53.0 one... In the end, I had to modify the theme code myself to achieve full compatibility with Serpent 55 I am not a user of TMP; on "caa:addon/tab-mix-plus/versions" I'm reading that the last version (0.5.5.0) supports Firefox 38.0 - 56.*; this is only an educated guess on my part, but I suspect TMP 0.5.5.0 is applying code to St55 written for Fx55 (breaking thus the customisation tab) when in fact it should've applied code for Fx53; in all fairness, this isn't an extension's fault (rather the app's misrepresenting itself...). I would go for a previous version like 0.5.0.2 ("updated for Firefox 53"); also, it wouldn't hurt to try the latest version on BitBucket, 0.5.6.0

I can reproduce with a new/clean Serpent 52 profile; after a few minutes of troubleshooting, it appears that the site does not like the default User-Agent string of Serpent; the fix is to change to Firefox compatibility mode; in "about:config", toggle "general.useragent.compatMode.firefox" to "true" and reload the page (it needs Adobe Flash NPAPI plugin): In an actual dirty profile, make sure to disable any content blockers for that site (I had to do so with uB0)

Works as expected here with Serpent 52.9.0 2019.03.23 (32-bit) in a new/clean profile, even without the preference in question (i.e. privacy.userContext.longPressBehavior;2): Works also in my heavily "dirty" Serpent 52 profile, but I don't have any tab-bar modifying extensions (actually, I do have Classic Theme Restorer, if that counts...). In your screengrab it looks as though you are using an extension which makes the tab-bar render in a vertical fashion (is it Tree-Style Tabs?), so the "new-tab-button" offered by that extension lacks the "Container Tabs" functionality exhibited by the original "+" button in the native tab-bar; IOW, @Mathwiz is right:

In Moebius, that "about:config" pref only controls the Release Notes link in the "about:" "internal" tab; the patch to make it also control the "What's new?" link in the "aboutDialog" box (pop-up window) was only committed by Moonchild during the UXP platform development phase; so it applies to Serpent 52 (and to the Release notes link in PM28) , but not its predecessor, Serpent 55; @roytam1 probably never thought it worthwhile to backport that UXP "cosmetic" feature to Moebius...

I just "refreshed" my memory by doing some tests with Release Firefox v53.0.3 32-bit (patched the executable so it would launch under Vista) and it turns out things are a bit different to how I remembered them in the Nightly 52.0a1 branch: 1. By default, Fx 53.0.3 does not ship with the "plugin.load_flash_only" hidden pref; instead I find the following ones: plugins.flashBlock.enabled;false plugins.navigator_hide_disabled_flash;false 2. Default "pluginreg.dat" file has version string "0.18t"; of the NPAPI plugins, only Flash is enabled by default (the rest are marked as [INVALID]). 3. In "about:config" I create a boolean pref named "plugin.load_flash_only" with value "false". I restart the browser! 4. New "pluginreg.dat" file is generated, with version string "0.18f"; all available NPAPI plugins are enabled; I did not have to delete previous version of the file (?). So, it seems at some point the Mozilla devs lifted the restriction that made the deletion of previous "pluginreg.dat" file mandatory in order to restore full NPAPI support in nightly-52.0a1... As to what it actually was that prohibited @Mathwiz's Serpent55 copy from detecting all available NPAPI plugins in his system, I am still questioning myself; one thing is sure: if you start transplanting existing profiles into other Mozilla forks, things are bound to break; Serpent 52.9.0 != FirefoxESR 52.9.x and, to a greater extent, New Moon 28.5.0a1 != FirefoxESR 52.9.x or even New Moon 28.5.0a1 != Serpent 52.9.0 ! (despite sharing the same platform). Likewise, Serpent 52.9.0 != Serpent 55 and Serpent 55 != FirefoxESR 52.9.x People changing browsers should always start with new, clean profiles, then selectively migrating parts from their previous profiles (bookmarks, passwords, etc) - extensions should be transferred with extra caution; what worked in one browser (e.g. FxESR 52) might not in the new one (e.g. St55); this is the cumbersome/tiresome way, but the safest way!

Beta/Release Candidate builds are routinely purged from the GitHub repo... If you want to install the WE flavour of uBlock Origin in latest Serpent55/moebius, then the latest available beta build (1.18.17b1 at this time of writing) is compatible with it; click the .XPI download link, allow "github.com" to install addons and you're good to go... However, to save anyone unnecessary trouble, recent uB0 versions have lost compatibility with FxESR 52+Serpent 52/UXP browsers (cosmetic filtering is broken, possibly other aspects of the extension), because the author has started using APIs present only in Firefox 53+ (despite the addon claiming it needs Fx 55.0 or higher); so, even if you force-install the addon in St52 (by modifying "strict_min_version" to "52.0"), it will underperform... There is a somewhat convoluted manual fix, which involves substituting .js files with their versions found in previous, compatible, uB0 versions, but that might be posted at a later time I find convenient; if you're on St52, you had better switch to uB0 legacy (currently at v1.16.4.10) ...

You're quite right! If you open file "pluginreg.dat" with a text editor (when the browser is exited), you'll see line 4: [3] [HEADER] [4] Version|0.18f|$ with a version string (0.18f in my case); if you toggle the controlling pref "plugin.load_flash_only" to "true" and restart the browser, then upon relaunch file "pluginreg.dat" will be regenerated having a higher version string; the Mozilla devs at the time authored code in such a way so that by simply toggling back the pref, one would not get full NPAPI support back; the version string of existing "pluginreg.dat" profile file was examined and if higher than a pre-defined value, the file wouldn't get modified; Mozilla shipped Firefox 53 with the pref defaulted to true (only Flash NPAPI allowed), so they put in an extra barrier for those "advanced" users that may have wanted to continue using other NPAPI plugins in their stable/release Firefox version; all this was done by Mozilla to protect the "innocent" from the unsafe/legacy NPAPI plugin technology! "Advanced" users in the mozillazine forums deciphered the "blocking code" and offered this fix for Firefox 53; yes, it works in the same way in Fx53, too: At the time, I was still Nightly-testing, that "change" first appeared in the 52.0a1 channel; by studying the relevant Bugzilla "bug" and lurking at the mozillazine forums, I became aware of the "fix"; by the time Firefox 54 was released (couldn't run it on Vista, of course ), much of the underlying NPAPI support code had been excised already, so the "fix" was no longer "valid" ... So now you know the whole story

When I first read the report by DanR20, I thought it was due to Serpent 52's WE APIs limitations (being somewhat inferior to the stock set of WE APIs found in FxESR 52); but then you went on to post: I did that test myself only to, of course, confirm your findings... But then I wondered... WTH would AMO label v4.0.1-4.0.2 as being Fx 52 compatible (51.0a1 to 56.*) when in reality, when installed, they don't work at all? Come @DanR20: So it was a Mozilla c*ck-up after all ... Sanity restored...

Quite the opposite is true; the now deprecated official Basilisk 55 (developed until March 2018) and the independent Serpent 55 fork maintained by RoyTam1, built on the Moebius platform, do both come with WE support, in fact better than their UXP counterparts... Official Basilisk 52/UXP was recently made devoid of all WE support, but that change was reverted by RoyTam1; so his Serpent 52.9.0/UXP fork does have some WE support (a subset of APIs from FxESR52) ...

I'll rephrase and expand that to: Since the moebius platform was initially forked from a Mozilla 53.0a1 platform snapshot, it comes with more Web Extension APIs than the Mozilla ESR 52.6.0 platform snapshot that UXP was forked from; so Serpent 55 supports more WEs than Serpent 52; FWIW, both browsers support a smaller subset of WE APIs than their Mozilla counterparts (Firefox 53.0 and FirefoxESR 52.9.x, respectively...); so while a WE may say it's Fx 52 compatible on AMO, it may not install (or perform poorly/if at all when it installs) in St52, while at the same time it installs and works OK in St55; in a similar vein, not all Fx 53 compatible WEs on AMO install and work as expected in St55 (e.g. latest Stylus 1.5.3 works OK in Firefox 53+, but is half-broken in Serpent 55; you need revert to Stylus 1.4.23 instead...). ... I've seen you post this previously and I let it go by, but for clarity's sake it simply isn't true: NPAPI Flash player plugin is still supported in Quantum (although not for long), so it'd have been odd if it weren't supported in a 53.0a1(+minor parts of 54.0+55.0) fork... As for the rest of the NPAPI ecosystem, I'd say St55's support is on par with FxESR52/St52; just make sure the following hidden pref defaults to false: plugin.load_flash_only;false If it's set to true (it's possible if you transferred a previous Firefox profile and did not create a fresh one), then toggle it and exit Serpent 55; locate its profile directory and delete file "pluginreg.dat" inside it. Restart St55 and it'll scan and discover all available NPAPI plugins...

If I am to respond to this query myself, I was indeed aware of the "Container Tabs" (aka Contextual Identity) browser feature being present in FxESR 52 (and thus inherited as dormant code inside the UXP platform) from my Firefox Nightly tester era; it was first offered as an experiment during the 50.0a1 dev cycle (June 2016) and was still present at the start (Nov 2016) of the 53.0a1 dev cycle when, alas, I was violently kicked out, as my OS became unsupported... I read that further down its development the feature was offered through the, now defunct, Test Pilot project, morphing finally into a standalone WebExtension addon (Firefox Multi-Account Containers - v4.0.2 the last compatible with FxESR 52). FxESR 52 shipped with the feature pref'd off by default; the hidden pref "privacy.userContext.ui.enabled", when toggled, exposes a GUI setting at the bottom of "about:preferences#privacy" tab, where the feature can be more easily enabled/disabled (toggling in effect hidden preference "privacy.userContext.enabled"). While that feature does hold promise, it actually never caught up with me, i.e. I rarely used it in Firefox; so at present I'd say I'm indifferent to its presence inside Serpent 52.9.0; in the few instances where I need an isolated (contained) tab, I make use of the Private Tab extension (as stated already) ... But my personal opinion shouldn't carry any weight in the decision-making wrt this feature inside Serpent; at least two other MSFN members+Serpent users expressed a wish it stays in, so I think the focus should shift to how many actually used it up until recently and have a concrete desire to continue using the feature in future Serpent builds ; I'm OK either way it goes!

FxESR 52.9.0 reached EoS in Sept 6th 2018, so for a short while during Sep 2018 (and possibly during the start of Oct 2018) MozillaESR 52 platform was still natively compatible with GitHub; the code GitHub served at the time to FxESR 52 was, at its greater part, backwards compatible with the Tycho platform (fork of MozillaESR 38), so, yes, GitHub was (mostly) working in NM27 back then; especially as @roytam1 went the extra mile to patch, after my report, the non-working "preview tab" under the "submit-a-comment" section... But as time progressed, GitHub moved on to officially targeting FxESR 60, sending back updated code, that was no more backwards compatible with Tycho (NM27); it happens to still be compatible with MozillaESR 52 + UXP, that's why browsers built on these platforms do work when spoofed to FxESR 60 ... Six months have already passed since the end of Sep 2018, quite a lot in terms of GitHub implemented code changes; it does appear as though major "legacy" browsers breakage occurred during the last month or so... Firefox versions < 52.0 don't function correctly at GitHub despite a SSUAO to FxESR60, because they can't handle served JS code; as for Chromium based browsers, I don't use them much, but here are my observations: 1. Google Chrome 49.0.2623.112 and 50.0.2661.102 (last working in Vista) could be made GitHub compatible via the User-Agent Switcher for Chrome extension and a SSUAO for GitHub as Opera/Vivaldi/Fx60; now, this no longer works (you don't get the yellow header about an unsupported browser version, but major parts in the webpage just don't work!) 2. Opera 36.0.2130.80 and 37.0.2178.54 (last working in Vista) would support GitHub natively, but they no longer do (even when spoofed to later Chrome/Opera/Firefox versions...). 3. Yandex Browser 17.4.1.1026 (Chromium 57 based) and 17.6.0.1633 (Chromium 58 based - last working in Vista) would support GitHub natively; currently they don't out-of-the-box, but you can resume GitHub functionality if you install aforementioned extension (User-Agent Switcher for Chrome) and add a permanent spoof (i.e. SSUAO) "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0" for domain "github.com" Currently in NM27 (as well as the other "legacy" browsers where GitHub is broken): Selecting a different branch via the dedicated button/wizard is broken; clicking the ellipsis in the commit title to expand it is broken; clicking the dedicated button to copy commit hash broken; various other more complex functions are broken, too (editing a previous issue/comment, "preview" tab in posts, etc.) Not the right person to ask that UXP browsers don't require an extension to make SSUAO work; this is a supported and native platform feature; as for FirefoxESR 52.9.x (where the feature is extant but dormant), I had toyed with the following extensions in the past; HeaderEditor 4.0.7 (WE) Custom User Agent 0.1.7 (WE) Custom User Agent 0.1.5 (jetpack/legacy) HTTP Header Mangler 1.1.3 (WE) HTTP Header Mangler 1.1.2 (jetpack/legacy) UAControl 0.1.3 + User-Agent JS Fixer 1.3 (both legacy) that all allow for URL/domain specific UA spoofing and, AFAICT, all performed the task brilliantly; lately, I have opted to ditch the UA modifying extensions and go for the "native" fix (by the insertion of the two .js files into InstalDir, see here). I don't use GitHub myself for code authoring/manipulation, but for every other feature I use it for, I encounter no issue when using latest New Moon 28[5.0.a1]/Serpent 52.9.0 with a SSUAO/FirefoxESR 52.9.x with a SSUAO; granted I, too, get a CSP error in WebConsole: but whatever it may actually signify, my GitHub usability seems unaffected... @Alex654, you seem very well versed when it comes to Javascript language, perhaps you should explain in more detail where exactly GitHub fails for you; other coders here could offer substantial assistance (other than me saying GitHub just works in NM28 ) ... Best regards

For starters, forget completely New Moon 27/Tycho; the platform is just too old (even with the rmottola/Arctic-Fox third party patches) to support the most modern JS/CSS code GitHub are employing... Since a few weeks ago, Mozilla 52 platform and its forks seems to be the bare minimum to support GitHub, but NOT out-of-the-box; GitHub's support policy is to support 1) current Firefox stable release (66.0.2) and 2) current FirefoxESR release (60.x.x); on older detected (via UA sniffing) Firefox versions, they're just sending unsupported code It just so happens that the JS/CSS code they send for FxESR 60 can still be handled adequately by FxESR 52 and the UXP platform browsers (official Pale Moon 28 - release & unstable - and Basilisk 52, and forks like New Moon 28.5.0a1, MyPal 28.4.1, Serpent 52.9.0 and Centaury 0.0.4; but in these browsers you'd have to use a SSUAO for GitHub to spoof FxESR 60: general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0 In the case of Serpent 52.9.0, I find a simpler SSUAO also works: general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.1; rv:52.0) Goanna/4.1 Basilisk/52.9.0 All UXP browsers support SSUAO natively; FxESR 52 has that feature disabled by design and you'd have to use specialised extension(s) or patch the browser yourself; see the discussion starting here What is indeed ominous is the fact FirefoxESR 60 is currently at version 60.6.1; when it reaches v60.8.x in 3-4 months, it'll be EoS and thus become unsupported by GitHub; then their ESR support will switch to v67; it is questionable whether the code they'll be serving to that would still be backwards compatible (via a SSUAO hack) with ESR52/UXP; I trust the Moonchild Productions devs would do their best to restore GitHub support in their UXP platform... PS: SSUAO = Site-Specific-User-Agent-Override

You could always give Infocatcher's Private Tab extension (caa:addon/private-tab) a try; I have it installed in latest New Moon 28.5.0a1 and I can report it's running satisfactorily there; e.g., I can use two different gmail/facebook accounts in two different tabs under the same browser window; but No Script isn't installed in my profile, so no way to know how it interacts with Private Tab

In UXP issue #756 they mention the MultiFox (legacy) extension; Classic Addons Archive (CAA) only has the v2 variety saved (caa:addon/multifox), but I managed to track down v3 on GitHub: https://github.com/hultmann/multifox/releases/tag/3.2.3 Supposedly, v3 has per-tab separate profile support, so it should replicate at least part of the functionality removed by the "beheading" of Container Tabs; not tested here, though...

Container tabs were removed from official Basilisk 52.9.2019.xx.xx upstream; this "code cleanup" was tracked in UXP issue #756 and finally implemented via UXP PR #834; the latest UXP changelog posted by @roytam1 here does have that code merged, so yes, the upstream changes made it to latest Serpent 52.9.0 (packages "basilisk52-g4.1.win**-git-20190330-843e4ceff-xpmod.7z); I bet Roy goes into the trouble of posting the official UXP changelog so that people can inform themselves...