VistaLover

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

... Old news now, of course, but here's the list of WS2008SP2 ESU Feb 2020 updates, as posted by the vendor themselves: https://docs.microsoft.com/en-us/windows/release-information/windows-message-center#388

You need to add the Iceape-UXP specific application id inside the extension's install.rdf file: <!-- Iceape-UXP --> <em:targetApplication> <Description> <em:id>{9184b6fe-4a5c-484d-8b4b-efbfccbfb514}</em:id> <em:minVersion>27.0</em:minVersion> <em:maxVersion>52.*</em:maxVersion> </Description> </em:targetApplication> Hyperbola provide an Iceape-UXP compatible fork of uB0-legacy, which they call uBlock Origin-Libre; unfortunately, it's only officially installed via their Package Manager; you can have a look at their (limited) set of extensions below: https://wiki.hyperbola.info/doku.php?id=en:project:iceweasel-uxp_addons As a workaround to the missing Package Manager, you can navigate to https://www.hyperbola.info/packages/community/any/iceweasel-uxp-ublock-origin-legacy/ and download the package via the "Download From Mirror" link; that will get you file iceweasel-uxp-ublock-origin-legacy-1.16.4.16-1-any.pkg.tar.xz Extract repeatedly with 7-zip and inside the ".\usr\lib\iceweasel-uxp\browser\extensions\" directory you'll find the needed .XPI file; install that manually on the iceape-uxp suite via drag-n-drop...

... Actually, my dear Italian friend , the last XP compatible version should be 6.047 ; you can fetch that from vendor's own "archived versions" repository: https://toolslib.net/downloads/viewdownload/1-adwcleaner/files/ => https://toolslib.net/downloads/finish/1-adwcleaner/851/ BTW, have you tried any higher versions on XP with .NET FW 4.0 installed? ... Of course, any Vista discussion is OT for this thread, but I had made several AdwCleaner tests on my own, reported below: FWIW, v7.4.2 launches fine here: ... But, binaries of the 8.x.x branch just silently fail to launch when double-clicked ; inspection with Dependency Walker does not reveal any vital missing function calls (only one in a delay-load dependent module), plus the executable's PE header has a Sub System version of 6.0, so I assume its devs have implemented a hard block on Vista in another way ; perhaps it requires a version of .NET FW > 4.6.1 ? In any case, though officially unsupported, v7.4.2 appears to be the last running on Vista...

Yes, the Tycho (platform) codebase was forked off Mozilla ESR 38 but (official) PM27, IIRC, comes with a native SSUAO for youtube; I don't have it handy ATM, but I believe it is advertising itself as Fx 42 to YT; low enough to make YT nag about it... I am delighted to report that YB 17.6.0.1633 (built on Chromium 58.0.3029.1633) gets served, as of this writing, the most recent YT iteration, i.e. Material Design with Polymer version 2 layout: (if you place the cursor on a video thumbnail, you get a video preview) Thus, I expect YB to work on YT for the foreseeable future; BTW, I composed this post using that very browser, so expect details of our exchange to reach President Putin's ears... (joking, of course... ) Best regards

My guess would be Update your browser for the best viewing experience. Actual link is (no surprises there) : https://www.youtube.com/supported_browsers Except for Firefox Browser (which is simply a Chrome wannabe ), all three other alternatives are Chromium based...

That's because FxESR 52 gets by default the (supported) Polymer v1 (Pm1) layout; only versions of Firefox older than 44 (Fx <=43) are being served the Classic layout, the one to be retired in March; if you use a UAO on FxESR 52 to spoof it as Fx 43, you'll get the older layout with the deprecation infobar: BTW, Firefox (Quantum) versions newer than 62 (63 =< Fx) are being served the newer Polymer v2 (Pm2) layout, which, on the outside, looks a lot like Pm1, but on the inside it's quite a different beast... FxESR 52 and the UXP browsers don't currently support it; of course FxESR 52 isn't maintained anymore, but MCP devs are already making talk about "upgrading" UXP to support Pm2 in the coming months; Google have not yet indicated for how long they'll keep supporting Pm1 Pm1 is considerably more resource hungry compared to the out-going Classic style, and this fact alone will create problems for older browsers capable of handling Pm1 but which are installed on old hardware (which seems to be the case with many XP/Vista users here... ) Of course, the forced migration to Pm1 will disable many user YT customisations, in the forms of XUL extensions, userstyles, userscripts etc., which were initially targeting the Classic layout; sadly, it'll be game over for those older browsers (on, perhaps, even older OSes/hardware) that can't cope with Pm1 at all... Some relevant links: https://support.google.com/youtube/thread/27596769 https://www.reddit.com/r/youtube/comments/eyjy4i/misc_fd_youtube_is_removing_the_old_design_soon/ https://forum.palemoon.org/viewtopic.php?f=3&t=23566 Chrome 49 has adequate support for Pm1, so if OP wants to continue using it for YT past March 2020, OP must: Install the User Agent Switcher extension from GWS: https://chrome.google.com/webstore/detail/user-agent-switcher/kchfmpdcejfkipopnolndinkeoipnoia Set a "Permanent Spoof" for youtube.com domain (aka SSUAO) and pretend to be Firefox 60 (e.g. Mozilla/5.0 (Windows NT 6.3; rv:60.0) Gecko/20100101 Firefox/60.0); then, every time a YT URL is loaded, OP will get the supported Pm1 layout without any nags about an unsupported browser: However, that workaround will, sadly, come to an end when evil Google decide to remove Pm1, too (which can be anytime, I hazard a guess and predict some time towards the end of this year) .

Posting duplicate posts asking the same query won't get you any popularity points here, plus it's against forum rules... https://msfn.org/board/guidelines/ @dencorso , would you agree?

... Yes, Yandex 17.6 (Chromium 58.0.3029.1633) appears to still handle successfully most sites I throw at it; if you additionally enable in flags (browser://flags/) Experimental JavaScript (it was experimental at the time Chromium 58 was released, most of it has become standard nowadays): browser://flags/#enable-javascript-harmony you'll increase considerably its compatibility with today's web ; even latest GitHub appears to function as intended with that setting turned on! Well, I can certainly understand your privacy concerns, but I have opted to use the Russian repacked X-portable (WinPenPack format) version of 360EEv12 here: The Russian modder has removed most of the telemetry features phoning Beijing (and this has been confirmed by fellow MSFN members in the relevant thread) : As one would expect, it's quite superior to YB in page rendering and RAM consumption/management, plus has full TLS 1.3 (final) support (which YB 17.6 lacks; only supports a previous to final draft); but its main drawback is that although you can manually install extensions from GWS, the browser can't check GWS for extension updates automatically (that's because Google services in general are banned in China); one has to check for extension updates manually on the corresponding extension's GWS page, export settings (for the ones that come with such a feature), remove the old version, manually install the updated version and manually re-import its settings from the back up file... BTW, I have stayed at version 12.0.1012.0 (current is 12.0.1053.0) because that's the last one in which the native dark mode (chrome://flags/#enable-force-dark) works without issues... I now see you have edited out that part in your last post (it's still there, though, in the e-mail notification of the original post ), because at first I got the impression my TeamViewer dedicated post had simply gone totally unnoticed... All the best

I'm not a TV user, so I had missed this unfortunate development... I went earlier on the official site to fetch and archive an installer of the last Vista compatible TV version, where I found the following notice: https://community.teamviewer.com/t5/Knowledge-Base/Which-operating-systems-are-supported/ta-p/24141 Unfortunately, the latest version is v15 (15.2.2756 to be exact) and I have confirmed it doesn't launch under Vista (due to missing function calls in Vista's system files... ); so, the last Vista compatible version, v14.2.x, can't be used anymore with a free licence... But even if you pay for a commercial licence, there are limitations: Sunsetting active servicing of operating systems That previous link suggests going to https://www.teamviewer.com/en/download/previous-versions/ for a v14 download; v14.7.13736 is displayed there (???); I am using NM28 and my UA does advertise my Vista OS (NT 6.0); the link to the installer is https://download.teamviewer.com/download/version_14x/TeamViewer_Setup.exe Upon clicking that, it redirects to https://dl.teamviewer.com/download/version_14x/14.2.56673/TeamViewer_Setup.exe which suggests a v14.2.56673 is the last Vista compatible TV version; however, it is impossible for me to complete the download, the browser generates an error, the wording is "The page doesn't redirect correctly" (translated from Greek); what gives? The portable download link https://download.teamviewer.com/download/version_14x/TeamViewerPortable.zip simply fetches v14.7.13736, which I confirmed doesn't launch under Vista... ; at last, I was successful in fetching the portable version of TV v14.2.56673 via the following, manually composed, link: https://dl.teamviewer.com/download/version_14x/14.2.56673/TeamViewerPortable.zip ... and I confirmed v14.2.56673 (portable) does successfully launch here (be it only after a considerable while since the main executable is double-clicked): ... But, the installer of v14.2.56673 is still a no-go for me... ... And do you want to know how I ended up getting that one? By requesting version 14.2.8352 (!) ; yes, the link (manually composed): https://dl.teamviewer.com/download/version_14x/14.2.8352/TeamViewer_Setup.exe will fetch: How MAD has this world become?

@roytam1 : Admittedly, I'm not closely following development on your palemoon27 branch (NM27 builds are only occasionally used here for testing ), but could you be so kind as to let me know why the latest NM27 build has a native SSUAO for github.com that advertises it as a mobile phone? general.useragent.override.github.com;Mozilla/5.0 (Mobile; Nokia_8110_4G; rv:48.0) Gecko/48.0 Firefox/48.0 KAIOS/2.5

Can confirm, new build based on toolkit: restore ResetProfile.jsm to previous state, fix about:support (so, in reality, new archive is more properly described by the filename palemoon-27.9.7.win32-git-20200202-aafa3ce17-xpmod.7z) Many thanks for the swift fix, highly appreciated!

Can confirm ; about:support is mostly kaput: The fact is upstream develop on Australis, while original Tycho is pre-Australis (just a guess of mine, hadn't taken the time to investigate further, as I've weaned myself from Tycho... )

Though a faithful uB0 user since its infancy, I don't consider myself an authority on it; besides, many other people here use it as their main adblocker, this is an open/public forum, everyone else (besides me) is invited to chime in and give a helping hand to those that might need it... My dear friend (and this is not meant strictly at you ), I, as much as the rest of the members here trying to offer solutions to other people's predicaments, post on a voluntary basis and to the extent other personal engagements (RL and digital one!) permit ; I'm not running a helpdesk service here, please acknowledge that, people ; thank you all in advance! Which browser is this happening on? I have to guess by a process of elimination, why are you being stingy in providing more details? FWIW, recent St52 builds do not connect any more on AMO to check for extension updates (and uB0 is not present in http://addons.basilisk-browser.org/ that is being checked); if one is at version 1.17.4[WE], then export all its current settings to a file, uninstall it, restart the browser and then install the latest legacy version from GitHub (1.16.4.16); import back your settings from the previously stored file... As for FxESR 52 and St55, these two browsers do still check for installed extensions updates on AMO; it is unfortunate that both the legacy and WE versions of uB0 have the same extension ID, so the XUL version gets updated automatically to the compatible WE iteration of it... ; but this is a known issue in these forums , it has been reported and described in the previous thread and solutions offered by several people, including both yours truly and @Mathwiz ... If you want to stick with 1.17.4[WE], then, for the WP site to work, apply the "fix" I already posted some posts above (which you appear to have disregarded : enable service workers! ) If you want to revert to the XUL (legacy) version of uB0, do as instructed for St52 - but make sure to first install the companion extension offered by @JustOff (a member of MCP and the Waterfox team): https://github.com/JustOff/ublock0-updater/releases/tag/1.6.9 This extension accomplishes two things: 1. Blocks update checks on AMO, thus preventing the unwanted update to the WE version 2. Directs update checks on the GitHub repo of the legacy version, making sure you get the latest legacy version; GitHub have a tendency of messing with this addon (by changing GitHub pages' source code ), so make sure you have that addon at its latest version, to be able to get the latest version of uB0-legacy. Then, for the WP site to work, you don't have to touch the service workers browser pref, the legacy version works out of the box! ADVICE to all: Your browser does have a bookmark feature, please use it to bookmark this post or any other one in this (long) thread you feel you might revisit later... My experience, based on using uB0 for many years, is that no adblocker is immune to detection, especially in recent years when advertisers and independent companies have developed dedicated anti-adblock solutions that are sold to webmasters ; it's a cat and mouse game really; uB0 offers an Adblock Warning Removal native filter list that you should enable, but, sadly, it's not enough Several other specialised adblockers have been created to combat the recent anti-adblock scripts (e.g. Nano Defender), but sadly, these come only as versions compatible with latest Mozilla Firefox and Google Chrome...

I have always felt that extension signing by Mozilla (another move of theirs to ape Google Chrome) just gives the user a false sense of security, certainly the non-advaned ones; I found it a real nuisance myself, so I would choose to use unbranded Firefox builds and/or switch to esr/aurora/dev/nightly channel, where the signing can be disabled via a pref... As such, I applauded MCP in their choice of not implementing it in their UXP browsers... And I can't help remembering the whole debacle some months ago involving an expired intermediate certificate, that caused most installed Fx extensions to be disabled, with no possibility to re-enable... Though signed, one can't be 100% sure an extension doesn't include malevolent code, this is true for both the Google Web Store (GWS) and AMO ; signing is basically an automated process now, I doubt addon reviewers manually inspect every new extension update (for existing ones) along with the truly new ones on AMO... This is slightly OT, but now Mozilla have segregated signed extensions on AMO to "recommended-by-Mozilla" and to the "not-recommended" ones (probably ones poorly reviewed, if at all), and the prospective user should exercise caution when installing one of the second group... So much for the value of the contained signature... Returning to uB0, I believe the version on AMO compatible with UXP is still signed; as for the legacy version on GitHub, this is indeed unsigned, but, unlike you, I trust gorhill (a Canadian, BTW) more that what has become of Mozilla these days; the code is still open source, let alone when a broader community of developers/advanced users, without hidden agendas (I can't, in all honesty, say the same about Googlezilla), keeps a vigilant eye over it... There's always a slim chance GitHub hosted files (now owned by M$) get hacked, but this is true for everything hosted on line (even Moonchild's ftp archive got hacked...). In any case, I'm not passing judgement in the slightest, anyone is totally free and independent to make one's own choices here - what works best for you, as long as varied choices remain available... Best regards

... My bet is @caliber is using the WE variety of uB0... (and, as such, he has to enable service workers in St52... ) Out of curiosity, what brand of ad blocker is it you're using? (I'd be surprised if you didn't use any, though... )

OK, when I visited that specific link in my "dirty" FxESR 52.9.1 profile, I found I could freely read the article and subsequently browse the rest of the WP site; once I fully disabled uB0-legacy, however, I could replicate the reported issue... Then it was a matter of finding out which specific filter list is responsible for lifting the WP imposed nags/limitations; below findings are the distillate of close to 45min of experimenting/troubleshooting: 1. The specific filter list in LEGACY uB0 (currently at version 1.16.4.16, to be found in its own repo now) which allows for uninterrupted WP browsing is a native one, uBlock filters, which contains the following code: ! washingtonpost.com##+js(abort-current-inline-script.js, Promise.all, _0x) !#endif washingtonpost.com##^script:has-text(adblocker) @@||securepubads.g.doubleclick.net/gampad/adx$xhr,domain=washingtonpost.com washingtonpost.com##div:has-text(We noticed you’re blocking ads.) washingtonpost.com##.db-ns[style="height: 1250px;"] washingtonpost.com##html[style="overflow: hidden;"]:style(overflow: auto !important;) ! https://github.com/NanoMeow/QuickReports/issues/1499 washingtonpost.com##section > div:has-text(/^AD$/) washingtonpost.com##:xpath(//*[(text()='AD')]/..) This is valid for uB0-legacy, which is compatible with all flavours of the UXP browsers, plus St55/Moebius (and FxESR 45 SSE, NM27 SSE/SSE2, but I don't normally use these... ) 2. In the off-chance someone is using the WebExtension flavour of uB0 on FxESR52 or St52 (probably 1.17.4)/St55 (1.18.x?), then, again, native filters inside uBlock filters allow for the nag-free browsing of the WP site; but there's a catch: for some reason I'm not familiar with, uB0-WE demands that service workers are enabled in the browser (they are OFF by default, at least in UXP); so, in order for the "Private Mode" sidebar nag to disappear, you have to set dom.serviceWorkers.enabled;true in about:config and make sure "uBlock filters" is selected in uB0-WE's third-party filters settings tab: FWIW, that WP site is a privacy nightmare, a veritable menace ; not only does it set a preposterous amount of standard and HTML5 cookies, just take a look at uB0's badge, where more than 1,000 requests are being blocked... Surely, there exist other avenues to learn the current affairs...

@ClassicNick : Fixed

... You're right, of course; I hadn't noticed, since I only attempted to fetch palemoon-26.5.0-20180718.win2000.7z I've taken the liberty of correcting them myself below: phoenix-0.5-cl933-tls12.7z classilla-9.3.3-win32-tls12.7z rzbrowser-tls12-20200127.7z retrozilla-suite-tls12-20200131.7z K-Meleon1.5.4en-US.tls12.7z KM74-g22-20180718.win2000.7z palemoon-26.5.0-20180718.win2000.7z