VistaLover

You've set it as default via the app itself ; probably a long shot, but have you tried using the OS for this setting? https://kb.wisc.edu/helpdesk/page.php?id=170#xp Do you still have Thunderbird 52.9.1 installed?

@Sampei.Nihira From the Microsoft link in your first post: https://docs.microsoft.com/en-us/windows/desktop/shell/start-menu-reg#registering-for-the-start-menu-email-link Matt A. Tobin has created the official Interlink e-mail client to target Win7+, so he may have deliberately removed the function to place registry entries under the "HKLM\SOFTWARE\Clients\Mail" registry folder (as this is a WinXP/WinVista requirement ); I'm tired now to go through his repository, but, hopefully, that intentional change can be reverted by Roytam in a future MailNews release...

... and KM-Goanna3:

Hello and welcome to the forums Technically speaking, @roytam1's New Moon 28 builds are being compiled from source snapshots derived from the master branch of the upstream UXP (= the application platform) repository: https://github.com/MoonchildProductions/UXP/commits/master This is, more-or-less, similar with https://github.com/roytam1/UXP/commits/master which gets synced with upstream before new binaries compilation... The exact source code from which the binaries are being compiled is best represented by the "custom" branch: https://github.com/roytam1/UXP/commits/custom which is official UXP + Roy's own changes... Given that the UXP master branch is being used for the compilation of the official Pale Moon "unstable" builds, https://www.palemoon.org/unstable/ simply put, New Moon releases are just forks of the official unstable Pale Moon update channel! But don't let the term "unstable" intimidate you one bit; Moonchild advises: so, to be on the safe side, just back-up your New Moon profile prior to updating your build (so you can restore it if something goes awry with the new build; you can always re-download a previous NM build from Roy's repository ); basically, just watch this thread and if something is broken with the release of a new NM28 build, it'll be reported and either fixed quickly via a re-issued build, or the "bug" will be properly addressed in the coming weekend's release... Personally, I've been using NM28 builds for many months, never have I suffered any data loss! I have no issue whatsoever with New Moon 28.5.0a1 while using the forum's post editor to submit/edit posts; but I'm not using No Script either... Adblocker used here is the "legacy" edition of uBlock Origin by gorhill, which works optimally with New Moon! No Script isn't just an adblocker but a more potent content-blocker, which has known issues with official Pale Moon and is not endorsed/recommended by Moonchild: https://forum.palemoon.org/viewtopic.php?f=3&t=19110 https://forum.palemoon.org/viewtopic.php?p=140965#p140965 Dedicated thread: https://forum.palemoon.org/viewtopic.php?f=46&t=19119 However, I understand several members here do use it with NM28, so perhaps it's them that should advise you better on how to tailor its settings to best accommodate the forum's post editor... Sometimes, it's not enough to simply disable No Script on a site for its effect to go away; you may have to temporarily disable the extension in about:addons and restart the browser or, even, have to uninstall it completely to test things; I would start by creating a new clean New Moon 28 profile and test there how the forum behaves; often times, the cause of issues is No Script conflicts with other(s) installed extension(s); you have to troubleshoot this yourself... Best greetings

Probably not... CTR itself as an extension targets the Australis GUI (Firefox 29-56), not Photon (Firefox >=57.0); I believe updated versions of CustomCSSforFx should be applicable in the Photon iteration of Waterfox 68.0a, but any such talk is still very premature... In any case, Waterfox discussion, methinks, should be continued in a more "appropriate" forum, seeing that the browser requires at least Windows 7 64-bit...

... Not quite ; "bootstrap" is just one category of "legacy" (i.e. non-WE) extensions, along with XPCOM, XUL overlay and jetpack; as such, they were indeed supported in Firefox 56.0.2 (last version with "legacy" support) and are still supported in latest Waterfox 56.2.9 ; what Jody wrote was actually: meaning that Waterfox v68α is Quantum based and will have the Photon GUI and WE support native to Quantum, but the Waterfox developer (Alex Kontos, of Greek descent) has somehow (?) managed to port to it "bootstrapped extensions" support... [ IIRC, early versions of Firefox Quantum, 57-58, especially in the Nightly and Developer/Beta branches, were able to support (at varying degree) classic extensions via flipping a pref (extensions.legacy.enabled); more here; as Quantum matured to > 58.0 version numbers, "legacy" extension APIs were eradicated to the point that pref, where still present, had no actual effect... ]

Nothing NEW here; I'm starting to get the impression your web searching skills are falling behind : https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Bootstrapped_extensions aka "restartless" addons; according to the page itself, Regards

Latest .EXE files (installers) have been uploaded now! http://faucet.aas.duke.edu/pub/pc/bigfix/patches/java/jre-8u211-windows-i586.exe http://faucet.aas.duke.edu/pub/pc/bigfix/patches/java/jre-8u212-windows-i586.exe But these are valid for Vista+ users, only ; Duke Uni DO NOT upload the .tar.gz archives necessary for XP ...

Your issue is most probably caused by the fact @roytam1's MailNews fork is being distributed as a .7z package and not as an installer ; an installer is needed to write the necessary registry keys so that Interlink/MailNews appears as one of the available installed mail clients ; I am on Vista myself (as I'm sure you know already ), but the related registry section should be quasi-similar in XP, too! In regedit, navigate to [HKEY_LOCAL_MACHINE\SOFTWARE\Clients] : the "StartMenuInternet" subfolder should contain the choices for available browsers; the "Mail" subfolder should contain available installed e-mail clients (mine are Microsoft Outlook and Windows Mail - the latter is the default Windows client, akin to XP's Outlook Express 6); every mail client should have a "\Capabilities\StartMenu" subkey in order for it to appear inside Start Menu's "e-mail" selection; in my setup, I use Windows Mail as the default client, its subkey looks like: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Windows Mail\Capabilities\StartMenu] "Mail"="Windows Mail" Probably additional registry keys are needed for the StartMenu entry to function properly (i.e. actually launch the client...). What one could do is install the official Interlink client on Windows 7+ with a registry monitor ON during the installation process, write down the new registry keys as a result of the install and somehow export them to the XP machine where MailNews is being used... As with any registry manipulation, take due precautionary measures... Hope I've pointed you towards the right direction; I trust our own MSFN perennial XP experts to chime in with more...

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