VistaLover

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

AIUI, it was NOT a question, but a piece of info; if you actually go to the link @Vistapocalypse provided, user @Csaba2 on "forums.comodo.com" is now testing CIS 2019 v12.0.0.6810 on his(/her?) XP SP3/2GB RAM (single channel memory mod)/1.8GHz proc machine; my own remark here wrt @Vistapocalypse's posted info is that it would've been more relevant to this forum/thread had a CIS 2019 tester actually been testing the Security Suite on a Vista machine ...

By spoofing a recent Google Chrome version (70/Win7x64) in FirefoxESR52 (see my previous post...) general.useragent.override.google.com;Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 I can get PAST the "... isn't supported by your browser, yet." message; however 1. Due to old gfx card driver (Toshiba modified, can't be updated to later version by vendor), some WebGL features are being disabled 2. I am met with Javascript errors; probably FxESR52 can't handle the recent JS code Google are feeding it...

Many thanks @Sampei.Nihira By slightly modifying the instructions in the last post of the mozillazine thread you linked to, I was able to restore SSUAO functionality in Firefox 52.9.0[1] 32-bit on my VistaSP2 x86 laptop and bring it on par with the UXP browsers (i.e. SSUAO are now possible natively, without the need for extra extension(s)) Full Guide (tested only in FxESR52, should work in other Fx versions): 1. Load "about:config?filter=site_specific" in a tab and make sure general.useragent.site_specific_overrides;true (should be by default) 2. Exit Firefox 3. Create the following text file pref("general.config.obscure_value", 0); pref("general.config.filename", "config.js"); rename it to "config-prefs.js" (make sure no hidden .txt extension is present) and place it inside <FirefoxInstalDir>\defaults\pref\ (a file named "channel-prefs.js" should already be there by default) 4. Create the following text file // needs to start with a comment line Components.utils.import("resource://gre/modules/Services.jsm"); Services.obs.addObserver(function (aSubject, aTopic, aData) { var chromeWindow = aSubject; chromeWindow.setTimeout(function () { Components.utils.import("resource://gre/modules/UserAgentOverrides.jsm", chromeWindow); chromeWindow.UserAgentOverrides.init(); }, 1000); }, "browser-delayed-startup-finished", false); rename it to "config.js" (make sure no hidden .txt extension is present) and place it inside <FirefoxInstalDir>\ (i.e. in the same directory as firefox.exe). 5. Launch Firefox; now you are ready to create SSUAOs inside about:config as you would do in New Moon and/or Serpent 52. E.g. I created general.useragent.override.browserspy.dk;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0 and when visiting the test site with FxESR52 I get: (to re-iterate, this is without any UA modifying extension... ). I think you'll find the above to your satisfaction...

Both Serpent 52.9.0 and New Moon 28 (currently in version 28.5.0a1) are built on the UXP application platform (and are forks of official Basilisk 52.9.20xx.xx.xx and Pale Moon [unstable] 28.5.0a1, respectively...). See: System requirements for UXP applications (Win) https://www.basilisk-browser.org/requirements.shtml http://www.palemoon.org/download.shtml => UXP platform's Javascript engine is such that it issues SSE2 instructions irrespective of compiler configuration; this is why NM28+St52 cannot be compiled for even SSE-only CPUs ... TL:DR: You are confined to your no-SSE NM27 builds...

Not needed at all if you download the extension [file uBlock0_1.18.4.firefox.xpi] (to disk) from the GitHub repository: https://github.com/gorhill/uBlock/releases/tag/1.18.4 Only Release/Beta Firefox branches observe extension signing (without an easy way to override it; one exists for Fx <=56, but it's OT here); Firefox ESR 52.9.0 (and the tinderbox build Firefox ESR 52.9.1), belonging to the ESR update channel, provides an easy way to disable extension signing via a user-configurable "about:config" pref: https://wiki.mozilla.org/Add-ons/Extension_Signing Nothing occult or clandestine here 1. Download file "uBlock0_1.18.4.firefox.xpi" to disk from GitHub 2. Using 7-zip, change "strict_min_version" to "52.0" 3. Disable extension signing in FxESR 52.9.1 4. Install modified extension file via drag-n-drop in "about:addons" There...

...Good to know ; when I started composing my post (which involved test installation attempts, taking a screenshot and uploading to the image hoster...), your "Edit" just wasn't there; and before I clicked "Submit Reply" in my finished post, I did not bother checking the status of your previous post...

I have AdvChrome v54.20.6530.0 32-bit installed in VistaSP2 x86; you should open chrome tab "chrome://extensions/" and make sure "developer mode" is checked on top right; then drag-n-drop downloaded file "uBlock0-1_16_18_0.crx" (signed) onto that tab; you should get a prompt to allow or cancel extension installation: if you don't, perhaps something's gone awry in your profile...

With all due respect to the author(s) of the Binary Outcast source code and the Trademark holders of related application names and artwork, the referenced "site" provides binaries compiled from forked code, code forked from the official Binary Outcast one; even in GitHub, when you fork a repository the forked repository contains at least one reference to the original repository in the form of a link to that one... So, in practical terms, what's the great harm if the original author/official brand name the derived product is based on is mentioned just once just to inform consumers of the products they're about to download? You mentioned in one of your earlier posts the possibility of "confusing" users; I'd certainly be confused under that scenario (i.e. when no info is provided about the hosted product). Under your same logic, the Waterfox browser people should make no mention whatsoever to Mozilla and/or Firefox, the platform/app they forked from; but they do, in fact, include the following disclaimer in all of their website pages (including the download page): Are they too acting in bad faith and/or in an illegal fashion? How is this different to @roytam1 having the following disclaimer: Apologies, I am not a native English speaker, so i had to look up "snarky" : https://www.urbandictionary.com/define.php?term=snarky How you'd go and describe Roy's "actions" as "snarky" and "backhanded" is completely beyond me (???) ; all that was done was to comply to the wishes/suggestions expressed in the linked MSFN forum post; well, the screengrab of that post was added for "posterity", you know, because posts can always be edited (just like "your coneys" was subdued to "your people"; BTW, I am noone's "people", I pride in not following "flocks" but make my own mind on things in both real and digital life...). I acknowledge several legal issues were raised with regards to the BinOC forked products (this is all very apparent to me now) and, as unpleasant as legal issues may be, these DO have to be addressed properly; this should have been conducted in an amicable manner, instead it has escalated into a Cold War Era confrontation, where each party is wary of the other and one party in particular is trigger happy, ready to push the "Nuke'em All!" red button... At the end of the day, while the lawyers might be satisfied, all that remains for mere mortals is the hostility and bitterness in the atmosphere - in the long run, this is detrimental to everyone... Regards

New Moon 28 and/or Serpent 52.9.0 also at peril? https://github.com/binaryoutcast/binoc-central/issues/73#issuecomment-467662459 (part of the binoc-central #73 thread...)

The Netflix screengrab you posted earlier mentions Netflix Error N8 156-6023; googling for that takes one to https://help.netflix.com/en/node/200 Make sure you have the very latest version of Silverlight 5 installed (5.1.50918.0); if you're on XP, read this First uninstall whichever Silverlight version already installed (if older) and then, for good measure, restart your system. Install the latest version; head to Start -> All programs -> Microsoft Silverlight (folder) -> Microsoft Silverlight (shortcut) and in the third tab (Playback) be sure to check "Enable download and updates to components required for protected content playback": Then, in the last tab (Application Storage), make sure "Enable application storage" is checked: Exit the Silverlight Configuration manager. I would test myself with a new, clean profile of New Moon 28 (you can back up your existing profile just for this test and restore it afterwards) to exclude any interference from user modified browser settings and/or extension interactions... Visit "about:addons -> plugins" and configure Silverlight to Always Activate. Check your Silverlight installation at http://www.radioactivepages.com/ If your Silverlight installation is in working order, then the (mechanical) clockwork on the top left should be moving: Time now to head over at the Netflix site; unfortunately, I don't have a (paid) account with them, so I can't move on past this point (I also searched - in vain - for a free, sample, Netflix video clip, but none showed up in my searches... ). After signing in and choosing a video for streaming, Silverlight should hopefully ask you to "play protected content"; say yes and it should just do that! (a bit of positive thinking never hurts in these cases ) I honestly hope I've helped...

... Two posts above yours

WidevineCDM, due to an update implemented by Google (current owner of the module) in early January 2019, is currently BROKEN in official Basilisk 52.0.2019.02.11 [and in the unbranded fork Serpent 52.9.0, when used in Vista+; WidevineCDM CAN NOT be used on XP in a Mozilla type browser, due to it needing access to system (OS) decoders (h264/aac) via Windows Media Foundation (an OS feature of VistaSP2+)]. This is currently being tracked in UXP #962 ; I see no recent activity there, admittedly it's not a task for the faint-hearted to adapt mozilla60esr code (merged with lots of Google cr*p) to UXP's EME code... Personally, I have little hope for a fix, but, who knows, maybe I'll be pleasantly surprised; if not, expect EME support to be probably also removed from official Basilisk, no wonder for "security" related issues . After all, no other app built on the platform currently (official Pale Moon 28, Iceweasel-UXP, BinOC's browser and e-mai client) has a need for EME/DRM... As for Netflix: Supposedly, older installations who have acquired licence keys via the now deprecated WidevineCDM version (1.4.8.1088) used in Basilisk will continue to work in old Basilisk profiles, but new/first time Netflix users in current Basilisk will fail to get fresh lic (decryption) keys and thus will be unable to stream Netflix... Netflix is one of the very few services that have a fallback mechanism to Silverlight NPAPI plugin on browsers not supporting EME (e.g. official Pale Moon), thus you can stream Netflix on PM28 with Silverlight 5 installed; PM28 has a native SSUAO for Netflix that forces it to fallback to Silverlight: general.useragent.override.netflix.com;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.9) Gecko/20100101 Firefox/45.9 95% of DRM'ed sites DON'T have the ability to use Silverlight (and Smooth Streaming) for their encrypted content and are broken in official Basilisk... To stream Netflix in official Basilisk (or in the unbranded fork), one must disable EME in the browser, install and enable Silverlight 5, implement the SSUAO for Netflix and restart browser; hopefully then Netflix streaming in Basilisk should work... Official Support Forum original thread: https://forum.palemoon.org/viewtopic.php?f=29&amp;t=21500

Again, many thanks indeed for keeping on breathing life into New Moon 27/Tycho ; it is much more lightweight and responsive in my old, SSE2 capable, Vista SP2 32-bit laptop than its 28/UXP counterpart, so it is preferred over the latter where both support the same websites... Sadly, as time goes by, a growing number of sites I frequent migrates to latest Javascript APIs, so NM27, due to its older JS engine, starts to fail at them at varying degrees... Currently, most issues are faced with GitHub pages/functions, they (GitHub) insist on using always the most up-to-date Javascript iterations, so this (i.e. NM27's shortcomings) is hardly a surprise ; so, for GitHub I am forced to using a UXP browser... Do the rmottola/Arctic-Fox devs target NM27's older JS Engine with the aim of bringing it closer to recent standards or are their contributions only targeting other aspects of the Tycho platform code? With each NM27 update containing several of their "changes", I hope part of my GitHub issues are fixed; alas, this wishful thinking has, to this day, remained as such... https://github.com/roytam1/palemoon27/commit/6d775ae - 27.9.1a1 + 27.9.6 I had been the first to suggest, many months ago, that a version string change (to >= 27.9.5a1) was necessary to easily reflect the fact the codebase has progressed significantly from the 27.9.4 release code snapshot, so, on the one hand, I am quite content that thing, be it belatedly, did take place . On the other hand though, I would've expected for you to stay with the "a1" version suffix, indicating an "unstable" channel, as you had been always building on MC's master PM27 branch (and, in fact, you do continue doing so with your NM28/UXP releases, forked from the "master" branch (official "unstable" update channel) for PM28/UXP). I could hex-edit PaleMoon.exe myself to change "27.9.6" to "27.9.6a1", but, as (bad) luck would have it, there exist only two NULL characters after "27.9.6" and the next text entry (actually the value of buildID), so this is not possible without breaking the compiled binary: And since I mentioned buildID, bumping appVersion to a "release" figure has an unwelcome (to me, at least) result; in the "About New Moon" info popup, the actual buildID string is no more displayed: I find that having the actual buildID string there (as was the case until now) to be very helpful, especially in troubleshooting scenarios... BTW, the code that controls the display of buildID in the "about" box is found within file "aboutDialog.js": // Include the build ID if this is an "a#" or "b#" build let version = Services.appinfo.version; if (/[ab]\d+$/.test(version)) { let buildID = Services.appinfo.appBuildID; let buildDate = buildID.slice(0,4) + "-" + buildID.slice(4,6) + "-" + buildID.slice(6,8); document.getElementById("PMversion").textContent += " (" + buildDate + ")"; } As you can see, it is only triggered for alpha (or beta) builds... Hopefully, you'll reconsider and opt for a 27.9.6a1 appVersion string for next release... Many thanks for your work, best wishes!

... Official download links from the official GitHub repository should always be preferred over third party generic "download" sites (like www.dobreprogramy.pl) : https://github.com/MrS0m30n3/youtube-dl-gui/releases/tag/0.4 Just my 2p, of course ...

(you and other eventual users: ) Be advised that: 1. This is NOT a true portable version, as it stores logs, settings and actually downloads youtube-dl.exe in "%APPDATA%\youtube-dlg" directory ; there's an open issue for this at https://github.com/MrS0m30n3/youtube-dl-gui/issues/65 2. The binaries of FFmpeg+FFprobe bundled with the package are NOT XP compatible (require Win7+); you should replace them with XP-compat ones (e.g. v3.0 from VideoHelp archive). 3. The project appears to have become an abandonware, at least for Windows users ; last Windows release (0.4.0) was July 2017 (though last commit activity was Oct 2018 ); in any case, I'm happy myself just using the CLI

... Especially when the likes of Matt A. Tobin drive away the very few that express such an intention: https://forum.palemoon.org/viewtopic.php?f=44&amp;t=21149