Re: Using Chromium instead, I do not want to support Mozilla because of their far left politics
Bold of you to assume that Google doesn't support censorship too (which they already do with their search engine), lol.
7 publicly visible posts • joined 26 Sep 2022
> Suggesting to such institutions that they change code which works perfectly in all major browsers for the benefit of a single minority-use broiwser is an exercise in futility.
Perhaps. But their insistence on making support for shiny new draft features mandatory and not letting smaller, independent browsers catch up will eventually bite them in the end. It's going to be an unmaintainable, expensive mess, because you keep refactoring stuff for no good reason. If they stick with the established, sane, and matured standards, they will not have that problem at all, and smaller browsers would be happy as well. Everyone is happy.
> A suspect a good compromise would be for PM to detect this particular error condition and allow users to permit this error.
How would this exactly work? How would a browser know whether it's really a SyntaxError or a real feature that isn't supported yet?
> Oddly, an early userland workaround, involving disabling HSTS via the Palemoon Commander utility, is no longer available as the disable option was removed from the utility.
That has been moved to the main preferences window, which means you no longer need an extension to have a GUI option for toggling HSTS.
> does anyone know what is in the string that seems to offend all these sites?
It could be the "PaleMoon" version string in the default UA mode. The server sees it, then doesn't know what to do with this "unknown" part of the string, then gives you a mobile version of the website if you're lucky, or if not, just refuses to serve you at all.
It could also be the version of "Firefox" it identifies as. Currently it's 68, because it's the best compromise at the moment (but this will change in the next 31.3.0 version where it will now identify as a "Firefox 102" in the default UA mode). Maybe the server thinks it's too old. So we up the Firefox version number. It could also be the opposite, in that it is expected some shiny new draft features would be available in Firefox 68 that Pale Moon doesn't have yet. We could drop the version down to say, 60. That's rare though, but it can happen more often if you set the compatibility version higher than 68. Facebook would just straight up refuse to load if you identify as Firefox 102 for example.
Useragent sniffing is a really BAD idea. It not only hurts Pale Moon, but SeaMonkey and other smaller browsers as well. Even Firefox sometimes get this problem from time-to-time; in their case it could be due to websites sniffing only for Chrome. Website developers should detect features, not versions.
Following well-known, sane, and mature standards is not arrogance in my opinion. The browser can only do so much, especially if it's being developed by a small team. The correct solution would be for those websites to actually follow the standards and not do some weird stuff with the JavaScript (which is often using draft features pushed by Google. I repeat, DRAFT features). This will not only benefit Pale Moon, but them as well, as it would be easier to maintain. Less is more.
> I'm not clear what the advantage of non-classic Waterfox is over Firefox ESR though.
Yeah, I'm curious about that. Wikipedia says it still supports all NPAPI plugins (not just Flash), but I wonder if that's still true. Mozilla has ripped out NPAPI entirely from their codebase.
> I tend to agree with you but my concerns are that Palemoon took an older version of the engine
If you mean that Pale Moon (two words please) is stuck in Firefox 52, this may be true during the time of the initial fork, but right now, no. A lot of stuff has been backported from newer versions of the Mozilla codebase, such as AV1 support, newer JavaScript features like the nullish coalescing operator (which had been a pain for us in the past in terms of web compatibility, but we have it now since June this year), etc.
> which lacks important features such as multi-process support
52 had e10s; it's just not enabled by default for all users. But we've intentionally removed any support for e10s in our fork of the Mozilla platform, as we believe multi-process is a downgrade in browser security and a spit to decades of systems engineering. You can read the rationale of the lead developer in this forum post: https://forum.palemoon.org/viewtopic.php?f=26&t=17442
Btw, just in case you don't bother reading the link above, this does not mean multithreading is not a thing in Pale Moon. Quite the opposite actually; we want to take advantage of multiple cores by focusing more on utilizing threads, not separate processes which the mainstream players are doing.
> Basilisk seemed to have something a little more modern, but also seems to have stalled over ownership issues.
Basilisk has the same exact platform as Pale Moon, so it's not "more modern". It does have more features enabled such as WebRTC and EME/DRM, which are intentionally disabled in Pale Moon. The Widevine DRM is currently useless however because Google refuses to give us a license for use of their content decryption module, and upgrading our in-tree DRM implementation would require a large and risky rewrite of the media code.
Basilisk has a new owner by the way, and I'm looking forward to having it replace my Firefox ESR for WebRTC.
> If XUL addons are still important, then Waterfox Classic is still around, still gets updates, uses the last ever version of the core engine (not merely the last LTS version) that supports XUL.
56 may look better as a fork point instead of 52 if you look solely at the version number, but it isn't that simple. Otherwise we would've used 56 as well. But there are problems with 56 which prevents us from creating a platform for multiple applications, instead of being Firefox-centric. We also don't want any Rust code in the platform. Which is why 52 was chosen, which has less bustage and less Rust code, making it easier to deal with.
> The Waterfox Project is open that there are security issues in it that they cannot fix and that they don't recommend or promote it because of this. The Palemoon/Basilisk project does not say this, but I am confident that the same issues and more also apply to them.
If you see any bugs in that list (https://github.com/WaterfoxCo/Waterfox-Classic/wiki/Unpatched-Security-Advisories) that still applies to Pale Moon's platform, it would be appreciated if you report about it (PM Moonchild on the forum if it's a serious security bug). But taking a random bug from there, I could see bug 1558299 already being fixed on our platform for example: https://xref.palemoon.org/goanna-central/source/platform/netwerk/base/nsNetUtil.cpp#1821
Anyway, I'm not here to evangelize and tell y'all to switch to Pale Moon. I know that some will be disappointed; we still don't have support for Google's proprietary extensions to regexp (which would require a wholesale overhaul of our JS engine), for example, nor do we still have support for the Google-centric WebComponents (which changes fundamentally our layout engine). There are also websites which in theory should be perfectly compatible with us, but refuses to do so (most likely due to useragent sniffing). For those websites dependent on those tricks, and workarounds such as the Palefill extension not working, I have Firefox as a backup browser. I believe we should all use the best tool for the job. And most of the time it's Pale Moon for me. :)