VistaLover

To be frank, I don't think they ever intended this for a massive consumption outside of mainland China; their site does provide rudimentary English localisation and the app, once installed, does have the option of a (poorly translated) English locale, but, beyond that, the browser is heavily China-centered (pre-installed Chinese search engines, default links to their own proprietary extensions store*, NPAPI+PPAPI flash [older version 29] downloaded straight from Chinese servers[IIRC, these are specially modified versions to allow better user tracking by the regime ], pre-installed Quick Dial with popular Chinese sites, support forum in Chinese only, etc., etc.)... What little English support exists is probably targeting foreigners already in China, for whatever reasons... Just my 2c, of course (*): While you can install most extensions directly from the official Google Store when you're outside of China, do note that the installed extensions can't access it for update checks, so no auto-update for said extensions is possible ; for those ones that have such a feature, you should first export to file their configuration/settings, uninstall the outdated version and then install from Google Store the updated version (unlike addons.mozilla.org, Google don't offer previous versions of an extension, and the new, updated, version can't be installed on top of the outdated one, retaining already existing configuration ); finally, import previous settings from file...

... Actually, stable build v1.1.453.59 has a digital signature of 2016-05-13 and is built on slightly fresher Chromium source (50.0.2661.102), whereas dev build v1.2.470.11 has a digital signature of 2016-05-04 and is built on older Chromium source (50.0.2661.89); so the snapshot build you're after is not more recent than the stable one I posted a link to... ... Yes, but only in (unsigned) ZIP format (which means you'll have to enable developer mode in vivaldi://extensions and install from unpacked folder; or, create yourself a .CRX file from within Vivaldi and permanently install that way... ). ... Knock yourself out Vivaldi.1.2.470.11.exe https://www15.zippyshare.com/v/bNiTojuc/file.html (Link availability at the discretion of forum admins... )

@artomberus ... Actually, the very last build of Vivaldi on the stable (release) branch that would run on Vista SP2 is 1.1.453.59, based on Chromium 50.0.2661.102 source code: The screengrab is actually from an unofficial portable installation (in PAF format); search for it on the web... Official link to the v1.1.453.59 (32-bit) installer: https://downloads.vivaldi.com/stable/Vivaldi.1.1.453.59.exe The very last build of Vivaldi on the snapshot (dev) channel that would run on Vista SP2 was indeed 1.2.470.11, based on Chromium 50.0.2661.89 source code: (... again, this is a portable installation in PAF format). The relevant vivaldi blog entry is: https://vivaldi.com/blog/snapshots/snapshot-1-2-470-11-editable-gestures-2/ but, as you found out, ALL binary links are 404'ed now... TBH, both builds date to May 2016, which means they are probably unsafe to browse today's web with, not to mention that many sites have dropped long ago Chromium 50 compatibility; YMMV, but poor site/page rendering is highly probable ; if you plan to install uB0, 1.16.18/1.16.20 is the last one (but hard to find as a .CRX file) that successfully works with those old builds... I only have on disk the 32-bit version of Vivaldi 1.2.470.11[dev] (file Vivaldi.1.2.470.11.exe, dig. sig. of Wed, May 4th 2016, 17:08:01), but I am unsure as to whether I am allowed to share it here... Don't have time currently to search exhaustively for an archived link for it (sadly, web.archive.org doesn't appear to have salvaged it )...

That's probably because your system lacks Eastern Asian Fonts (Chinese, Korean, Japanese, etc...); not saying you'd be able to understand the messages in Chinese (displayed by the installer) had you got them installed... Perhaps a native Chinese speaker could create an installation guide with screenshots for those wanting to install this Chinese Chromium 69 fork (myself, I'm using a Russian-made portable version in WinPenPack format, just search for it on line as it's not allowed here on MSFN to post links to "unofficial" packages... ).

... As posted elsewhere, 45.9.0esr was the last 45esr version officially released by Mozilla (mid-April 2017): https://ftp.mozilla.org/pub/firefox/releases/45.9.0esr/win32/it/ 45.0esr (very similar to stable 45.0) was from March 2016; during an ESR branch update cycle, only security updates, chemspills (urgently needed fixes for various breakages) and some quality/performance updates are being backported from the main (stable/release) Firefox branch (with higher major version numbers...); system/CPU requirements don't change in the middle of an ESR cycle, when they do, it's always beginning with the next ESR cycle; e.g. all 45.x.xESR builds will run on max-SSE processors, none of the 52.x.xESR cycle will (likewise, all 52.x.xESR builds will run on XP/Vista, but none of the 60.x.xESR cycle will ) Simply put, 45.9.0esr has more than a year's worth of publicly disclosed security vulnerabilities patched; as to whether those put a perceivable dent to the whole browser performance, as suggested, I can't comment really ; test on your own particular setup and decide for yourself; if you ask me, though, I'd go for safer...

... You "sound" surprised ; if you please read more carefully previous posts in this thread and/or inspect related commits in Roytam1's GitHub repository (as the result of Mathwiz's PRs), you'd realise ONLY NM28/UXP and (some of) Serpent52/UXP "Help" entries were altered... If, OTOH, you are truly asking for Mail News's "Help" entries to be modified, that's a different matter; AFAICT, @roytam1 hasn't published a forked Binary Outcast GitHub repository (unlike his UXP one!) one can then re-fork and submit the necessary PR... He, of course, can do this in his local BO repo, if he agrees to your requests... NB: I am NOT a user of any of the BO forks (nor will I choose to be )...

Actually, this is NOT accurate; Avast does provide 19.x versions of their Free Antivirus flavour; e.g. if you navigate to https://www.avast.com/download-thank-you.php?product=FAV-AVAST&locale=en-gb you will end up downloading from: https://bits.avcdn.net/productfamily_ANTIVIRUS/insttype_FREE/platform_WIN/installertype_FULL/build_RELEASE which, once on disk (337 MB, off-line setup), can be verified to be of file version 19.4.4318.0. But versions 19.x require Win7+, the version you have installed (18.8) is the last supported one on Vista/Server2008 ... Cheers

... I understand this was a change implemented on a platform level, so I'm not sure as to if/how what I suggest below is feasible, but what would be best, IMHO, is to implement the upstream change ONLY to New Moon (application/palemoon) and NOT implement it on Serpent (application/basilisk); removing the "force-enable e10s" feature on NM should be favourable, because force-enabling e10s on PM/NM, even for testing purposes, will produce a totally broken/unresponsive browser (as the internal e10s supporting code is non-existent in PM/NM); just my 2 eurocents, of course

If you have access to a Win7+ computer, then consider installing KAF19 (Kaspersky AntiVirus Free) on your off-line XP machines ( as suggested by @BTTB ) and then use latest Kaspersky Update Utility on the on-line Win7+ machine to download latest KAF19 definitions: The "def" files can be then transferred to the XP machines via, e.g., a USB flash stick and then installed via a process probably detailed in the Kaspersky Support Site (or just Google/Bing/DDG for it ). EDIT: Support link => https://support.kaspersky.com/11705 Unfortunately, latest KUU v3.2.0.153 is build on Qt 5.8 framework, which requires Win7+ (thus, I can't test it here on Vista... ). EDIT2: Last XP+Vista compatible version of KUU is v3.1.0.25 (built on Qt 4.6); official download link (retrieved via web.archive.org ): updateutility_win_3.1.0.25_release_en.zip Once run for the first time, start an update to populate the "Applications" list with latest KAF entries...

@Mathwiz's PRs have been now merged into @roytam1's custom UXP branch, expect to see the changes landing in tomorrow's NM28/St52 builds... On another note, the few (?) of you running Serpent 52.9.0 in forced multiprocess (e10s) mode ( @Mathwiz, still doing this? ), will soon be unable to continue this practice, considering the upstream dev has patched that loophole: https://github.com/MoonchildProductions/UXP/issues/1130 https://github.com/MoonchildProductions/UXP/commit/19c0f5e

@TechnoRelic I have already made my position very clear in the matter at hand, in previous posts of this thread: I feel totally indifferent to the whole re-branding issue, in fact I am quite alright with how things were/are now; @roytam1 is NOT compiling builds with the official branding, this is crystal clear; the whole re-branding argument has been always pushed by MCP and/or Matt A. Tobin; I am not confused in any way as to what I am using on my Vista laptop currently ; I might sound harsh, but Roy is NOT to blame whenever some NM/Serpent user knocks on MCP's door; the fault lies, IMHO, solely on those users, who can't tell their right hand from their left one (and, as said already, full rebranding won't relieve MCP of random NM users and/or make them think about us - maintainer+users - in another way; for them, we'll always remain XP+Vista freaks ) ... The recent PRs by @Mathwiz were submitted after you have, apparently, taken sides with MCP/M.A.T in your recent post ; you have yourself appointed only myself and Mathwiz as the users who should be consulted about your "re-branding" expectations, but this leaves out numerous other NM/St users who might not be as vocal in the forums here, but their own opinion should also carry weight... Mathwiz created his PRs as an interim and "easy" solution, with the hopeful aim of deterring additional NM users from seeking support at MCP's HQs; twice you said "is FINE with me", but it now becomes apparent, even after the PRs have been created, that you won't feel satisfied unless a full rebranding takes place: in other words, in your own subtle way, you are coercing @roytam1 to proceed into full re-branding, echoing MCP/M.A.T 's agenda... Roy shouldn't be forced to make any additional efforts, he's working wonders as it is, regularly providing browser builds for a plethora of older OSes/platforms... And this is my final say on this...

Nope ; the correct official avast forum topic with links to both off-line/on-line installers is: https://forum.avast.com/index.php?topic=220639.0

This is a tough one to solve ; selecting in Serpent 52.9.0 "Help => Keyboard Shortcuts" is, code-wise, contained in: https://github.com/roytam1/UXP/blob/master/application/basilisk/base/content/baseMenuOverlay.xul#L55-L56 <menuitem id="menu_keyboardShortcuts" oncommand="openHelpLink('keyboard-shortcuts')" The code to execute the command is contained within: https://github.com/roytam1/UXP/blob/master/application/basilisk/base/content/utilityOverlay.js#L818-L823 function getHelpLinkURL(aHelpTopic) { var url = Components.classes["@mozilla.org/toolkit/URLFormatterService;1"] .getService(Components.interfaces.nsIURLFormatter) .formatURLPref("app.support.baseURL"); return url + aHelpTopic; } The default value for app.support.baseURL is https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/ so the URL returned is https://support.mozilla.org/1/firefox/52.9.0/WINNT/en-US/keyboard-shortcuts which then auto-redirects to https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly?redirectlocale=en-US&as=u&redirectslug=Keyboard+shortcuts&utm_source=inproduct ... As for the browser.slowstartup.help.url, I merely proposed what appeared to me as a simple (but functional) enough solution, provided @dencorso obliges ; but, since this is basically your PR and your call, you are free to proceed as you see fit...

... And why would you not link to this very MSFN thread? It would be consistent with what is already displayed in @roytam1's binary repository: https://o.rths.cf/palemoon/?sort=date&order=desc Index of /palemoon/ Welcome to New Moon (a.k.a. Pale Moon fork targetting XP) binary directory. These projects have no affiliation with any upstream community code sources or organizations. Please direct all support or related questions to disscussion thread in msfn.org. So, my recommendation would be: app.support.baseURL;https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-fork-targetting-xp/ WRT http://www.palemoon.org/support/slowstartup.shtml , this is just an adaptation from the corresponding Firefox guide: https://support.mozilla.org/en-US/kb/firefox-takes-long-time-start-up Admittedly, the PM page is better tailored to New Moon users, but, again, that page is copyrighted to MCP and has references to official app name, logo and support forum, so... Perhaps @dencorso can somehow transplant the following text: as second post to this very thread, then the URI to that post could be used as value of pref browser.slowstartup.help.url ( I am against this myself, but one can supposedly disable a "slow start-up" page from appearing by toggling pref: browser.slowStartup.notificationDisabled; this will disable the notification and the access to the support page ).

Thanks. I'll make the necessary fix and create another pull request, probably tonight. ... Have you looked at my own post on this subject?

Latest version 0.49b 1. Has rectified the oversized/elongated app window 2. App window can now be minimised to taskbar 3. App window can't be maximised or resized 4. There is no more a right "sidebar", but the test result is being displayed in the bottom "status bar" 5. As with previous versions, 200 sample hosts are being checked against... I ran the app on my Vista SP2 32-bit old laptop (so can't tell whether it runs under XP SP3 ), 0 detections and 7 handshake failures here...

@Mathwiz: https://github.com/roytam1/UXP/blob/master/application/palemoon/app/profile/palemoon.js https://github.com/roytam1/UXP/blob/master/application/palemoon/app/profile/palemoon.js#L82 https://github.com/roytam1/UXP/blob/master/application/palemoon/app/profile/palemoon.js#L927 We need the location of the code to be modified inside the Source Code, not inside the compiled application ...

The "instagram" issue in UXP browsers (NM28, Serpent 52) has been covered in fine detail in previous pages of this thread, when it first manifested itself ; it's a case similar to player.pl, that is due to new UXP defaults (general.useragent.compatMode.version;60.9), instagram sends JS code the platform can't cope with... The solution is similar to the one suggested for player.pl, i.e. use a SSUAO for instagram that advertises a Firefox < 60.0 version; DON'T touch the "general.useragent.compatMode.version" pref, just create: general.useragent.override.instagram.com;Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

@Mathwiz For troubleshooting purposes, things are much easier when using portable packages/installations; for example, official PM28 (recently updated to v28.5.1) is being distributed also as a WinPenPack portable "setup" (in reality, an extractor): You can substitute the contents of the "Bin" directory (respecting folder tree) with latest NM28 binaries... The portable package comes by default with an empty profile (found inside the User directory); by running the portable launcher, you instantly get a pristine/default browser profile to test with! NB that this portable installation does not interact with your "installed" NM28 version, but they shouldn't be run concurrently while testing... When you want to start fresh with a new clean profile, just back-up/trash the previous one (while the browser is exited) and when you then re-launch Palemoon-Portable.exe, it's like the first time all over again

The same file mpengine.dll is used inside mpam-fe.exe (MSE manual definition updater) and mpas-fe.exe (manual definition updater for Vista+Win7's iteration of WinDefender); while MSE itself is NOT officially supported under Vista, Vista's native WD (for some undisclosed reason) IS, as one can see by visiting: https://www.microsoft.com/en-us/wdsi/definitions Microsoft Security Essentials 32-bit | 64-bit Windows Defender in Windows 7 and Windows Vista 32-bit | 64-bit So if M$ decide on breaking mpengine.dll on Vista (make it only Win7 compatible), they will intentionally quit supporting Vista's WD antimalware solution; but it's their prerogative, you know ; Vista has been EoS for more than two years, Vista users are currently at M$'s mercy (and if one of you "XP-ers" decides to visit MSFN's thread pertaining to installing Windows Server 2008 SP2 updates on Vista, one will clearly see that things have started falling apart recently... ).

Try to install it.xpi from: https://ftp.mozilla.org/pub/firefox/releases/45.9.0esr/win32/xpi/ (not tested )

Nice catch (... and that's another reason why I always advise to check first on a new/clean browser profile in the case of found "issues" ).

... Dumb question, but has it been verified via Dependency Walker that the new engine file still remains XP incompatible? Engine version 1.1.16000.6 (file mpengine.dll) works OK under Vista SP2, too...

... Would you really? First, you'd have to acknowledge that Serpent 52.9.0/UXP and Serpent 55.0.0/Moebius are two different applications on two different platforms (because I often sense a notion, shared by many here, that they are, in fact, quite similar ...); the former is under active development by the upstream devs, while the latter only receives the occasional "experimental" update by its current maintainer... MCP have changed pref general.useragent.compatMode.version in St52 to value 60.9; this means that the Firefox portion of St52's UAS claims rv:60.9, this alone satisfies GitHub's needs and "github.com" should work out-of-the-box; with recent builds of St52, one does not need a SSUAO for Github per se: (on Vista:) Mozilla/5.0 (Windows NT 6.0; rv:60.9) Goanna/4.2 Basilisk/52.9.0 unless the global UAS has been modified to something claiming older Firefox versions... semi-OT: To ensure better compatibility with the largest number of sites, I have turned ON both Gecko and Firefox compat modes: general.useragent.compatMode.firefox;true general.useragent.compatMode.gecko;true so my global St52 UAS reads: Mozilla/5.0 (Windows NT 6.0; rv:60.9) Gecko/20100101 Goanna/4.2 Firefox/60.9 Basilisk/52.9.0 In the case of Serpent 55, the value of pref general.useragent.compatMode.version has remained at 55.0 (<60.0), additionally Gecko & Firefox compat modes are defaulted to true; this means github.com sees the client as Firefox 55: Mozilla/5.0 (Windows NT 6.0; rv:55.0) Gecko/20100101 Goanna/4.0 Firefox/55.0 Basilisk/55.0.0 , hence it gets broken and doesn't work out-of-the-box there... You have several options to restore GitHub on St55, the one I suggested was to use a SSUAO which doesn't contain any Firefox portions (github.com gets "confused" and serves moebius compatible code): Mozilla/5.0 (Windows NT 6.0; rv:55.0) Goanna/4.0 Basilisk/55.0.0 ... or you could modify pref general.useragent.compatMode.version to 60.0; in that case, the global UAS will read: Mozilla/5.0 (Windows NT 6.0; rv:60.0) Gecko/20100101 Goanna/4.0 Firefox/60.0 Basilisk/55.0.0 and github will work (but "instagram", "player.pl" and possibly others will break...). To conclude on this, my tests have shown that you can use in St55 the same SSUAO that works in St52 (which, as explained, doesn't necessarily need one!) to restore GitHub functionality; e.g., I just used Mozilla/5.0 (Windows NT 6.0; rv:60.9) Goanna/4.2 Basilisk/52.9.0 successfully in latest Serpent 55.0.0

Latest Serpent 55/Moebius works fine on GitHub here, if the following SSUAO is employed for domain "github.com": general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.1; rv:53.0) Goanna/4.0 Basilisk/55.0.0 Proof (new clean profile, no extensions): Forgiven ; but you did scare the cr*p out of me! I thought we were good at least until Quantum 60.x.x becomes EoS later in the year...