VistaLover

Bk52 (the browser, as test application) was initially built by upstream on top of a fork of the Mozilla ESR 52.6.0 platform code; the derived platform is named UXP. Since then, both the original official Basilisk 52.9.x upstream project as well as roytam1's Serpent 52.9.0 fork have significantly diverged from that starting point, but have also diverged significantly between each other, too... IMHO, stating that Serpent 52 is "based on FF52 code" is no longer descriptive of the current situation... Bk55 (the browser, as test application) was initially built by upstream (Moonchild Productions) on top of a forked Mozilla Nightly 53.0a1 snapshot platform code, with very few 54.x and 55.x code elements merged in; the platform that was produced was named Moebius; the app (browser) built on top of it was named Basilisk and was given an app version of 55.x.x, for (if you ask me) sensationalistic reasons ; much of the initial Moebius code, hence, can be described as a pre-53 Firefox snapshot... Serpent 55 by roytam1 was forked off Bk55/Moebius; that upstream project was abandoned in favour of UXP (and Bk52/UXP); since then, St55 is being infrequently maintained as a code melting pot, merging bits of various other upstream projects (e.g. UXP, tenfourfox, Mozilla and even code from IceWeasel 53.x). TL;DR: Current Serpent 55.0.0 has extremely limited affiliation, codewise, with stable Firefox 55.0

... Being slightly pedantic, but the URL query parameter should be: disable_polymer=1 Be that as it may, the query no longer works for the main YT homepage, https://www.youtube.com/?disable_polymer=1 (classic style is not restored), but still works for independent video URIs: https://www.youtube.com/watch?v=W-z7hoEWaH4&disable_polymer=1 A Google-bot SSUAO however does, as of this writing, work in both cases... [I'm using just "Googlebot/2.1 (+http://www.googlebot.com/bot.html)"]

... But he has already stated that:

... For spell checking in 360EE v12, I'm using the following Chrome Web Store (CWS) extension: Grammar and Spell Checker - LanguageTool ... currently at version 3.1.6 - works quite well, albeit with a bit of fine tuning; I'm only enabling it when inputting text, like in this case... (Like all extensions from CWS when installed on the patched version of 360EE v12, they are not checked automatically against CWS for newer releases, one has to do that manually, say, once weekly, and install the updated version also manually; NB: if you first uninstall the old version (in order to then proceed with the upgrade), all custom settings of the extension will be removed - better first back up the settings, where available...)

... New Moon 28 DOES NOT support WebRTC and the same stands true for (upstream) official Pale Moon 28/29; this has been a long-standing decision made by the Moonchild team, I think after a user poll; main considerations are security and performance toll on the browser... The team currently spends very little time on the WebRTC part of the (UXP) platform code, which is mainly still present (inherited initially from Mozilla ESR 52.6.0 platform) for the sake of Basilisk 52.9.x ... In theory, you could build yourself a custom build of New Moon 28/UXP with the --enable-webrtc config flag, but if you are a social media sites fan (where WebRTC is mostly used), then opt to use for that purpose Serpent 55.0.0/Serpent 52.9.0, where WebRTC is built and enabled by default... Or switch to another browser (are you on XP?) with WebRTC support (probably all Chromium derivatives and, though I don't use it myself on my Vista laptop, MyPal 28.9.3) ... Personally, I avoid ALL social sites like the plague (for security/privacy/performance issues, etc.), so I have currently no need for WebRTC and the like; pretty happy then with NM28 not supporting it... However, I am a democratic person by conviction and respect the right of other people wanting something I consider a nuisance...

Upstream issue #1570 has been closed via commit e5dd97f ; when @roytam1 merges this, the issue should be resolved in next weekend's UXP builds; the issue has been caused by reddit opting to use the latest (ES2020/2021) javascript bells and whistles , breaking in essence all "legacy" browsers... If, like me, you hate infinite scrolling (which is more suited to mobile devices with touch screens) and prefer the previous ("old") reddit layout - much more lenient on resources - then, as suggested by @Montana Slim , you can use (auto-)redirection to "old.reddit.com", which is made very easy via userscripts like Old Reddit Redirect ; for New Moon 28/Serpent 52.9.0, you'd need Greasemonkey for Pale Moon v3.31.4 Should you also want to revert to the previous reddit favicon, then userscripts to that purpose also exist, e.g. // ==UserScript== // @name Old Reddit Favicon // @include https://old.reddit.com/* // @grant none // ==/UserScript== (function () { var link = document.querySelector('link[rel*=\'icon\']') || document.createElement('link'); link.type = 'image/x-icon'; link.rel = 'shortcut icon'; link.href = 'https://i.imgur.com/veJX9o5.png'; document.getElementsByTagName('head') [0].appendChild(link); }) (); (... harvested from https://old.reddit.com/r/Enhancement/comments/7jd9a7/any_reason_for_new_favicon_it_looks_terrible/dr5l2k2/) 360 Extreme Explorer v12, a Chinese Chromium 78 fork, that is able to run on Windows XP SP3 onwards, does not suffer from this issue; you'd better flip the flag #enable-javascript-harmony to Enabled (followed by a restart) and you can use latest reddit without issues (including infinite scrolling...) : (the above is with build 12.0.1268.0 and dark skin/forced dark mode... )

... I think you did not view the screenshots posted by @RainyShadow ; the issue isn't that the about:support internal page doesn't load; it does, but it isn't populated with all the expected info/details one should find there: Reproduced on a new/clean NM27 profile, on Vista SP2 32-bit

If anyone of you, XP diehards , uses Transmission as a bit-torrent client, I have posted the bad news over at the Vista subforum:

Just like qbittorrent towards the end of last year, another open-source bit torrent client, Transmission, has progressed past Windows Vista (and XP) support ... Transmission is a well known bit-torrent client, especially popular among Mac users, preffered due to its low memory footprint on the host system; its home site is hosted at: https://transmissionbt.com/ while the open-source code is hosted at GitHub: https://github.com/transmission/transmission While the back-end is cross-platform, the Windows port/front-end builds on the popular Qt Framework (much like the Windows port of qbittorrent); over the last two years, official releases appeared to have remained stagnant at version 2.94 (issued on May 1st 2018), built with Qt FW 5.6.0. Some days ago, new official release v3.00 came to light which, most sadly, has minimum WinOS requirements met by Windows 7; v3.00 has been built using Qt 5.14.2 which, by itself, denies any XP+Vista support; earlier in this very thread it was detailed that the last Qt version with FULL Vista support was 5.6.3 (with some rare app exceptions cited that manage to run under Vista while built on Qt 5.7.x/5.9.x); it's still possible, because I haven't bothered to check, that the core Transmission code now intentionally targets Win7+ and thus the breakage is not entirely due to the move to a higher Qt version ... To cut it short, Transmission v2.94 from 2018 is now the EoS'ed version for both Windows XP SP3/Windows Vista SP2: (official links to MSI installers:) transmission-2.94-x86.msi transmission-2.94-x64.msi With the popular (but adware/bloatware/spyware) uTorrent application having abandonned XP+Vista several months ago, the addition of Transmission (along with qbittorrent) to the list of bit-torrent clients that aren't maintained anymore under Vista limits extremely the choice of such a client under that OS (with, off-the-top-of-my-head, the closed-source Tixati being one of the last available choices... ) ...

@dencorso : Methinks the above two posts are just outright "plug" attempts for the referenced payware software manufacturer ; new MSFN user @rryan22 has just subscribed 6 hours ago with the (apparent) sole intent of making those two posts... And while the country of origin has been declared as the UK, the quality of the English language used points more to a translation machine/web bot, e.g.: Just to be on the clear, I have nothing personal against payware (coders certainly have to make a living) or people without an adequate command of the English language (which is the default in these forums...). However, unless @rryan22 has personally tested every individual piece of payware software he has mentioned as the last one working on Vista/Win2k, then I'll continue to treat his posts as disguised advertisement attempts... BTW, should any of the claims made be true, why isn't a transparent approach of accessing those older, still payware, software versions offered?

... About the france.tv issue: Troubleshooting from outside of France: 1. Geo-block circumvention As one would expect, this is a media portal site which streams copyrighted audio-visual content, intended for a specific country/region (in this case France); I haven't bothered checking one of their LIVE streams (which are usually the ones most heavily protected against "illegal" access), but chose a VOD URL: https://www.france.tv/france-2/eurovision-europe-shine-a-light/1468469-emission-du-samedi-16-mai-2020.html They first check geo-location via https://player.webservices.francetelevisions.fr/v1/geoloc where they note the requesting client's timezone, plus they then check actual physical location via https://geoftv-a.akamaihd.net/ws/edgescape.json These APIs can't be fooled with an "X-Forwarded-For" request header hack, so to pretend to be in France you'll have to use a whitelisted French HTTPS/SOCKS proxy or a French VPN... One good source of "open/misconfigured" French proxies suitable for such tests is http://spys.one/free-proxy-list/FR/ I picked one with small latency and good speed (http://195.154.41.246:5836) and configured New Moon 28 to use it for all connections... 2. Actual testing I used the latest NM28 offering (package: palemoon-28.9.3a1.win32-git-20200516-a8f7300b9-uxp-9cf4eca9a-xpmod, buildID=20200515224638) with a new, pristine, profile. I verified the issue reported by @IXOYE with the French proxy in use; thankfully, the screenshot of the NM28 Error Console (btw, the poster was asked to provide Web Console logs, which would've been more verbose, better for troubleshooting) mentions "polyfill.io/v2" and this started ringing some bells... It turned out the "france.tv player" issue had been already previously reported in the upstream support forum: https://forum.palemoon.org/viewtopic.php?f=3&t=24269 and the cause is that sites still using the old polyfill.io/v2 library (the current is v3) break in Pale Moon (hence NM), because v2 doesn't detect NM's features well and chokes (more: https://forum.palemoon.org/search.php?keywords=polyfill) ... The workaround is to use a SSUAO for "cdn.polyfill.io" advertising latest Mozilla Firefox: general.useragent.override.cdn.polyfill.io;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:75.0) Gecko/20100101 Firefox/75.0 This fixes the issue for me, at least on NM28 and a VOD: However, be warned that the SSUAO suggested above, while it does fix the france.tv issue, it may break other websites which also use polyfill.io, especially if they have upgraded to its version 3... FWIW, NM28 is being served by france.tv player MPEG-DASH unencrypted (no DRM) streams, which are also geo-fenced at the manifest/CDN level ; one MPD manifest I managed to sniff is of the template: https://cloudreplayfrancetv.akamaized.net/7400cc4850ce5/229118575_france-domtom_TA.ism/manifest.mpd?hdnea=exp=1589845397~acl=%2f7400cc4850ce5%2f229118575_france-domtom_TA.ism*~hmac=79fe0976ca3c2982afbf17e1ba2e4d06255857c968f01229a33f37cb5c712cd9 If/when france.tv move to full encryption/DRM, requiring current Widevine support in the browser, then it'd be game-over for XP/Vista users, because latest widevine DLLs require Win7 as a bare minimum...

... It is my understanding that even the SHA-2 only code-signed installers (standard/debug) will install and function OK on a fully updated XP SP3/Vista SP2 system, it's just a minor irritation though that the OS+user can't verify the validity of the code signature...

... And for my XP friends here, since the officially provided installer (.exe) won't launch under Windows XP SP3, I hereby provide the official (but hidden behind a mandatory Oracle account ) link to the extractable jre-8u251-windows-i586.tar.gz archive/package that XP users can use to manually update their JRE8 installation: (32-bit:) https://javadl.oracle.com/webapps/download/AutoDL?BundleId=242059_3d5a2bb8f8d4428bbe94aed7ec7ae784

Adobe Flash Player plugin has been updated recently to v32.0.0.363 (replaces previous version 32.0.0.344); here comes the bad news: if one composes and uses the "standard" link template for the SHA-1 only code-signed official distribution packages (installers), http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.363/install_flash_player_ax.exe http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.363/install_flash_player.exe http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.363/install_flash_player_ppapi.exe then the downloaded binaries are, sadly, ONLY SHA-2 code-signed ; people following me in the Vista subforums would already know that I've installed a relevant Windows Server 2008 M$ update that enables reading/validating SHA-2 code signatures (but which, at the same time, "upgrades" Vista SP2 to build 6003, denying it completely from M$ update servers ), so that is the reason I can produce the following screenshot (for NPAPI v32.0.0.363): For history books, the below (now non-working) links for v32.0.0.344 were indeed able to fetch SHA-1 only signed installers: http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.344/install_flash_player_ax.exe http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.344/install_flash_player.exe http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.344/install_flash_player_ppapi.exe (for NPAPI v32.0.0.344): @Bersaglio , can you confirm and are you able to offer alternate links to SHA-1 Adobe Flash Player packages?

@FantasyAcquiesce Thanks for your info... BUT... The latest version available on the linked site is 3.0.205.0 and yes, min Windows version compatible is Windows Vista (32-bit and 64-bit) - no surprise then that the client wouldn't run under XP... The downloaded standalone installer has a digital SHA1 signature of May 20th 2018 ; even worse, when the installer is extracted/installed, the browser has a buildID of 20150421120931 (i.e. April 21st 2015); in this case, New Moon is just a generic UNBRANDED fork name, not to be confused with @roytam1's unbranded builds... The BlackHawk browser build is based on Pale Moon 25 (platform is Gecko 25.3.0), so extremely outdated security/features-wise ; IMHO, that browser deserves an entry inside digital history books, not installed in one's Vista machine today... (OT: I honestly hope you're well - stay safe )

... This isn't quite accurate... An SSL labs server test, https://www.ssllabs.com/ssltest/analyze.html?d=ffmpeg.zeranoe.com reveals that the hostname resolves to two IPv6 and two IPv4 addresses (4 in total); selecting, for example, the first IPv4 one (104.24.105.227) : https://www.ssllabs.com/ssltest/analyze.html?d=ffmpeg.zeranoe.com&s=104.24.105.227 ... one can see that the site supports even TLS 1.0 (which is why it is capped with a B mark): However, you are right in saying that the site can't be accessed on XP with browsers that rely on the OS crypto libraries (like IE8/Chrome 49), and this is reflected on the test site as well: ------------------------------------------------------------------ Handshake Simulation Chrome 49 / XP SP3 Server sent fatal alert: handshake_failure IE 8 / XP No FS No SNI Server sent fatal alert: handshake_failure ------------------------------------------------------------------ ... however this fact is purely because: === This site works only in browsers with SNI support === SNI requires Vista at minimum; FWIW, I can load the Zeranoe forums site with IE9 on my Vista SP2 laptop... OT: I hope you're all well and staying safe, away from Covid-19 infection...

... To make this even more clear, CAA is NOT a collection of extensions, but simply a database, a list if you will, of legacy Firefox extensions scraped off AMO before Mozilla removed them from sight... The actual XPI files are hosted externally, in a hosting space (CDN) kindly provided for free by the Waterfox community (so please, do not abuse their bandwidth ); as you can imagine, the actual total size of the hosted XPIs amounts to many GBs... The CAA .xpi file itself, when installed, expands to an SQLite database of ca. 62 MB (to be found in ".\<profilefolder>\ca-archive").

@PPeti66x : You are being served the mobile version of GitHub... And the reason is that recent versions of New Moon 27 have a default SSUAO for GitHub of the following kind: general.useragent.override.github.com;Mozilla/5.0 (Mobile; Nokia_8110_4G; rv:48.0) Gecko/48.0 Firefox/48.0 KAIOS/2.5 i.e. mobile Firefox 48.0; I can't pinpoint the exact commit this was introduced, nor the reasoning behind its implementation; the https://github.com/roytam1/palemoon27/commits/master repo is very hard to browse/troubleshoot, as each commit is the sum of many squashed commits, involving the patching of too many individual code files... All I can assume is that was just a decision made upstream, i.e. by rmottola/ArcticFox. You can change that SSUAO to report a desktop browser, e.g. general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.0; rv:52.9) Gecko/20100101 Goanna/3.4 Firefox/52.9 PaleMoon/27.9.7 and that setting will get you back the desktop version of GitHub : Be advised though that both the mobile and desktop versions of GitHub are severely crippled/broken on NM27, because the platform/browser engine does not have adequate support for the Javascript version/features that GitHub requires as a bare minimum... FTR, I composed this post in latest NM27 and it has serious issues/bugs with the MSFN post editor, too... Actually, hadn't used NM27 for more than a year, alternating between NM28 and Serpent 52 ... ... C'mon, surely you can do better than that...

FTR: https://forum.palemoon.org/viewtopic.php?p=185808#p185808 @Alex654 and others feeling the urge to do that: PLEASE, NEVER TAKE ISSUES SPECIFIC TO NEW MOON/SERPENT to the official Moonchild forums! What you'll only achieve is to cause additional aggravation to the devs (especially to a certain Mr. Tobin) who, as most people here know already, harbour animosity towards the forks for "old" OSes... The thing is, I have fought hard in these threads in the past so that the New Moon 28 fork doesn't deviate significantly from the official Pale Moon code with respect to language strings, in order to keep parity with the official PM language packs which, I stress, are only being produced to target (and be fully compatible with) official Pale Moon! The fact that we were able to install and use the official LPs (to be more precise, the ones compatible with NM28 were the ones offered by @JustOff to target the official unstable Pale Moon builds) was just a side bonus, these packs do contain the official branding and I'm sure the MCP devs weren't/aren't happy we were using them to begin with... Due to certain coding decisions taken by our maintainer ( @roytam1 ), the custom UXP fork branch he's compiling NM28 off has distanced itself from upstream (which already uses a different build system, i.e. official unstable PM29 is now being compiled from a dedicated PM repo, with official UXP as a module), so that the LPs currently produced by @JustOff are simply not compatible with New Moon; from past discussions, it is my belief that we are not to see any updated LPs for New Moon coming from @roytam1 himself, so I guess it's a task to be undertaken by the user community...

... But OP confirmed this in ... which, to me, sounds like OP used an installation medium with integrated SP2...

Additional links: 1. From a browser with a UA advertising XP/Vista (NT<= 6.0) : https://browser.yandex.com/download?full=1 2, Using any UA: http://download.cdn.yandex.net/browser/_xp_builds/int/en/Yandex.exe http://download.cdn.yandex.net/browser/update/17_4_1_1026_2644_w_s_m/yandex.exe FTR, the downloaded file has a digital signature (it's dual signed, i.e. both SHA1+SHA256) dating from September 24th 2017 (not Mar. 2017, as stated...) The above behaviour is by design; only per user installations (not global) are allowed by the installer: https://yandex.com/support/browser/about/install.html That means the global installation directory (%PROGRAMFILES%) is not used, only the current Windows account's HOME directory (%APPDATA%) is... Their documentation describes what, to me at least, appears to be a fairly standard way: Anyone following my posts, especially in this thread, will surely know I'm an avid fan of Portable software installations, especially in the PAF format; this "love-affair" with portables began a long time ago, when I had a very small C: drive and I thus had to try/install various apps in my second, external USB, drive (then D:); also, having both the program's core files and settings in the same directory becomes very handy when you want to "re-install" or carry the fully customised program to a different host... While currently I have ample disk space in my "OS" drive, the habit of portable installs has endured all these years... However, in the case of Yandex Browser 17.6, the portable "package" is the ONLY way, because the proper YB 17.6.0.1633 installer is very hard to come across, plus it's been (artificially) blocked from launching under Vista (and, as I recall, I did mention this fact somewhere previously in this very thread... ); so, the available 17.4 installer being only capable of "per user" installations was not the reason I had chosen "portable" in this case... Best regards

Huge thanks, indeed

@roytam1 : I want to raise your awareness to upstream UXP issue #1446 : Only allow extension class add-ons to use the dual-GUID system Now, Moonchild has tagged this as "App: Pale Moon", which means, for the time being at least, they'll only be enforcing this on Pale Moon... In NM28 I'm currently using a native Full Theme (Dark Moon 2.4.1), but it's possible other members here are using Complete Themes made for Firefox originally (so these will stop loading if/when #1446 is merged into NM28)... However, on Serpent 52 I'm using, since very long ago, an "originally-for-Fx" Complete Theme, FT DeepDark (v14.3+slight local modifications); the following two upstream commits Only allow extension add-on types for Firefox compat mode Only match extension add-on types for target applications were pushed into the upstream master UXP branch (i.e. platform-wide), which, IIUC, is "mirrored" in your own master UXP branch and then selectively merged into your custom UXP branch (the one used to produce the UXP forks); IOW, I harbour some slight trepidation that, if due diligence is not paid here, suddenly my FTDD complete theme will cease working in a soon to be released Serpent 52.9.0 build... Thanks for your consideration on this matter, huge gratitude in fact for keeping your projects "going" despite adverse real life conditions ... Take the best of care!

I've noticed this yesterday (Feb 15th 2020), using several different browsers, being logged-in/logged out and with my content blocker (on which MSFN ads are allowed ) OFF - I've cleared browser cache, restarted browser, all to no avail ; actual flags are missing for me...

With a total sum of 3GB of RAM, I'd definitely opt for a 32-bit flavour of Vista, especially in the case of an under-resourced netbook; and, as advised already, I wouldn't go past Home Premium on that machine (the only thing I'm missing in HP is the Group Policy Editor ... ). Just my 2 cents...