VistaLover

Thanks for that! I've now bookmarked that third party Adobe Flash Test page, it's nice, desired even, to have an alternate test page, besides the Adobe official one...

... But all Mozilla devs live under the illusion that constantly aping Google Chrome (by removing native browser features and GUI customisations, delegating removed features to WEs instead) IS the way to deter Fx users from changing camp over to the competition, ie. Chrome! They've also assigned a "name" to this illusion, it's "Chrome parity" (!) But, as you say, the net result is quite the opposite...

Does the previous version of NPAPI Flash (32.0.0.270) work there? Of course, just a sample of two people (works for one, doesn't for the other) has no statistical value...

Cannot reproduce here: New clean profile of latest St55 (32-bit) on Vista SP2 x86 - NPAPI Adobe Flash properly installed systemwide:

If you want to hide from view various addon-related warnings inside Firefox's AOM, but don't wish to install CTR just for that function, then you can achieve the same using the following CSS code (inside a userstyle manager, like [legacy] Stylish 2.1.1 or Stylem, or inside your chrome\userChrome.css file in your browser profile) : @-moz-document url-prefix(chrome://mozapps/content/extensions/extensions.xul), url-prefix(about:addons) { .warning { visibility: collapse !important; } }

It's funny you mentioned SSUAO in Firefox, because today I became aware of another Mozilla change involving SSUAO support in Firefox... During the pre-Australis era, Mozilla had implemented native SSUAO support in Firefox (but I'm now too lazy to search and quote relevant Bugzilla bugs, it's 01:50 AM on Friday already here...), but then disabled it at some point (in Fx 25.0 ?) in desktop Firefox (but kept it in the mobile version) to, supposedly, gain a 7% speed increase in page loading times... The feature supporting module (UserAgentOverrides.jsm) was still kept in the source tree, but was not initialised in desktop Fx versions - hence the need of an extension (or additional code) to re-initialise it properly in Fx ESR 52.9.x In a previous MSFN post, I had searched Bugzilla and found that the SSUAO native feature was again restored in Fx 55.0, so from Fx 55.0+ one would not need extensions (legacy/WE) or JS code to apply SSUAOs in the browser... However, it appears that this native useful feature was again binned, starting with Firefox Browser (previously known as "Quantum") v71.0 (currently in the beta channel); this time, the original SSUAO supporting module (UserAgentOverrides.jsm) was completely excised, reason being "it was just old code", and those users wanting the removed functionality back should, once again, resort in using a dedicated (WE) addon... I was alerted by the following Mozillazine thread: http://forums.mozillazine.org/viewtopic.php?f=23&t=3055169 Bugzilla bug #1513574 : Remove UserAgentOverrides.jsm Once again, I beg to differ...

... Pardon me dear dencorso, but this was first made public on Jul 25th, 2017, more than two years ago already; so, most people browsing the web today should be sort of aware of the "crónica de una muerte anunciada" of Flash... On that same vein, there was recent discussion in the official Moonchild forums regarding Flash deprecation: https://forum.palemoon.org/viewtopic.php?f=3&t=23191 and Moonchild himself stated: But, come the end of 2020, NPAPI Adobe Flash won't be further patched for security; if MCP leave NPAPI Flash support in, as stated, then it's up to individual users to decide upon themselves if the inevitable security risks are really worth sticking to Flash in PM/Basilisk...

Sure you can: Do you, by any chance, have the sidebar displayed? (Because for me, when the sidebar is ON and the tab content width shrinks, the "</>" button disappears from the MSFN post editor's header... )

Of course, I can't deploy Waterfox in my Vista SP2 x86 laptop, but a targeted GitHub search reveals plenty : https://github.com/MrAlex94/Waterfox/pull/566 Thanks, but it's useless when it goes live (i.e. in your original post, I can only switch between "Hide contents" & "Reveal hidden contents" state, while the actual "content" is void); you need to document (pun intended!) this function by stating plainly the code to be used inside MSFN's post editor... EDIT: So it should look like this [spoiler] contents [/spoiler] which, when submitted, turns into Thanks

... But don't actually pay attention to what other people made the effort to post ... I did mention the reason in the part you chose to ignore: When MCP chose to remove WEs support from UXP and official Basilisk, it was a perfect chance for them to switch Basilisk's AOM (WebExAM) to the one present in Pale Moon (TychoAM) - PM's AOM dates from a pre-Australis era, has no support whatsoever for WEs and, as stated by Aris, displays addon version number by default. But it was decided (by popular demand here) to keep WEs support in Serpent 52.9.0, that meant staying with the original AOM shipped with UXP, pretty much the same as the one in FxESR 52, which supports WEs but doesn't display addon version number by default (an additional legacy extension is needed for that, e.g. CTR). In CTRv1.7.8.2019.xx.xx, Aris removed the .css code that enables the WebExAM to display addon version number (by selecting that option in CTR), since it's now a native feature of the TychoAM present in official Basilisk. Please read for more info: https://github.com/MoonchildProductions/UXP/commit/2cbbc5d https://github.com/Aris-t2/ClassicThemeRestorer/issues/402 https://github.com/Aris-t2/ClassicThemeRestorer/issues/408 Regards Addendum: Mozilla had intentionally removed the default display of AVN (addon version number) in the Australis[later WebExAM] AOM back in Firefox v40, when Bugzilla bug1161183 landed: https://bugzilla.mozilla.org/show_bug.cgi?id=1161183 This was again an unnecessary move, a type of "chop head to get rid of headache" approach, since the bug originally wasn't about AVN per se... https://bugzilla.mozilla.org/show_bug.cgi?id=1161183#c10 Remember, that was back in 2015 and already Mozilla devs had an opinion on what is of use in the browser GUI to most users, the rest were deemed to be few... I guess @roytam1 would have to revert that bug in both Serpent 52+55 (which use WebExAM) for CTRv1.7.8.2019 to be used as wished by @Mathwiz; but I don't think it's needed (now me sounding like a Mozilla dev...): if one is adamant on installing CTRv1.7.8.2019 in Serpent (which, I emphasise, is maintained with only official Basilisk in mind!), may co-install the following legacy extension: Version Number in Add-ons Manager 1.10 (by magicp), recoverable via CAA (caa:addon/addonvernumber) (Hope this time post is NOT ignored... )

... You are developing a habit lately of not closely reading my posts (just kidding, of course! ) : So, for both Serpent 52/55, CTR_v1.7.8 IT IS; CTR_v1.7.8.2019.10.27 applies to official Basilisk (on Win7+) and Classic Waterfox... Should be possible to read posted fixes/changes in https://github.com/Aris-t2/ClassicThemeRestorer/releases after Classic Theme Restorer 1.7.7.2 and including Classic Theme Restorer 1.7.8

Out of curiosity, I downloaded that MS update from the link in the KB article; that fetched file "excel2010-kb4484164-fullfile-x86-glb.exe", sized 36.1 MB (!). I can confirm this is only SHA-2 code-signed: You'll have to test file code-signing signatures in a fully updated Win7 system (or higher) or, in my case, in Vista SP2 with one of the WS2008SP2 updates which give the OS SHA-2 code-signing verification support... Trying the Windows Update Catalog link (mentioned in that same KB article), http://www.catalog.update.microsoft.com/Search.aspx?q=KB4484164 I ended up with a different file, excel-x-none_a5b150722cca4d6d9b062063747b02df0eaaaf51.cab (sized 19.8 MB); extracting it yields an excel-x-none.msp file (Windows Installer Patch, sized 40.3 MB), which is also only SHA-2 code-signed; notice that on the MUC, only a generic version is offered, regardless of the OS on which Office 2010 is installed ; perhaps the .exe and .msp files check OS version when launched, but it didn't occur to M$ that XP+Vista don't support SHA-2 code-signatures; there was a specific update on Vista (KB2763674) that allowed for .exe file execution even in the case the .exe was only SHA-2 signed, I guess a similar one might exist in XP (as part of the POSReady ones?) ... The deal breaker here is that Windows Update on both XP and Vista was never patched to deliver updates signed with only sha-2 code signatures - for WS2008SP2, such an update does exist, but when that's installed on Vista, it changes the build number of Vista to 6.0.6003 - but that cuts off Vista completely from WU servers , because they were only configured to serve Vista 6.0.6002 builds; it emerges that WU servers are intelligent enough to tell apart Vista 6.0.6003 (blocked) from WS2008 6.0.6003 (supported); so, starting with Nov 2019 (and for the remaining updates till Oct 2020), users of Office 2010 SP2 on XP/Vista should manually install applicable updates from either MS Download Center/MUC... ( ... and you thought M$ would screw Office 2010 only on XP, by sending incompatible mso.dll files... )

... I was under the impression Disney+ launched initially only in the US, Canada and The Netherlands... https://www.cnet.com/news/disney-plus-streaming-service-launch-dares-prices-shows-movies-marvel-star-wars-pixar/ Aren't you currently in Poland?

If they're using DRM (with no Silverlight NPAPI fallback), then 1. Any version of Pale Moon (official 27.9.4 runs on Vista, official 28.x.x doesn't) or New Moon don't have any support for EME, DRM and the WidevineCDM needed to decrypt the DRM'ed streams. 2. If you're actually using the Serpent 52.9.0 fork, able to run on Vista, then I have seriously bad news to tell you: while St52 does support EME/DRM, the version of WidevineCDM it is compatible with is 1.4.9.1088; that version was revoked by Widevine licence servers (owned by Google) on Aug 13th, 2019. There is a task underway by a Moonchild Productions developer to port support to latest official Basilisk for currently supported WidevineCDM v4.10.1440.19; this task is currently stalling due to real life issues affecting that developer; even if/when that attempt reaches fruition, it is a moot point for the Serpent fork on Vista; new WidevineCDM dlls contain functions (actually, only one: TryAcquireSRWLockExclusive, Win7+) not compatible with Vista's kernel32.dll system file; as WidevineCDM is proprietary closed source code and Google don't support the CDM on Vista, there's practically 0 chance DRM services requiring WV will ever work again on Vista If Disney+ use DRM with WV, then, if you can, try Firefox Quantum 60.9.0/68.2.0 (with WV v4.10.1440.19) on a supported OS (Win7+); or the latest Chrome there; as I can't try D+ myself, I speculate your predicament is DRM related; if they don't employ DRM - highly unlikely - then some other member here (in the US, CA or NL) might throw some light... PS: If you don't grasp some terminology in this post, Google is your friend (actually, in the above WV context, your foe... ). Regards

No, he's right: Pale Moon (28) is the official browser by Moonchild Productions that targets Win7+; the fork maintained by @roytam1 is a yet unbranded one, with the (interim) name being New Moon, that adds (restores) XP and Vista compatibility to the browser; over the course of development, Pale Moon and New Moon (and certainly Basilisk and Serpent) have diverged even further, beyond the initial point of New Moon being just "Pale Moon for XP"; also, you're kindly asked to refer to the fork as New Moon only, because using the official branding (Pale Moon) when actually meaning the fork tends to aggravate the upstream developers (who then make angry appearances here and lash out at the fork maintainer and users...). I realise you're a new addition to the MSFN forums, I'd like to welcome you, too, but kindly advise you to get some facts straight first by reading existing threads... Regards

... A pain? In what way? Re-installing on top of an existing installation should leave the app's settings intact, AFAIAA; if the app is "properly" installed, then all (custom) settings are stored in the registry; the GUI of the app provides a very handy feature to export its settings as a .reg file, which can be imported (merged) later, after a new (re-)installation, to restore the player's settings like before: Another scenario is if you're using a "portable" installation, where you selected the setting "Store settings into .ini file": In that case, you only have to back-up that .ini file (in my case, it's PotPlayerMini.ini, but I'm on Vista...) found in the "installation" folder, to be put back in place after a new (re-)installation... So, me thinks you're just exaggerating... Best wishes

(The discussion topic here is horizontal scrolling via mousewheel ) Hi ; most members frequenting this thread are on Windows XP (or older OSes), with the exception of the few Vista users like me; not all of such members have ready access to Win7 or higher... I tested several Firefox versions (up-to-and-including v53) that would run in my system, I wasn't able to enable HS in any of them, via either of the following "mousewheel.with_*.action" prefs: mousewheel.with_control.action;4 mousewheel.with_shift.action;4 It turns out that HS was enabled in Firefox only as recently as v58.0: Horizontal Scrolling with Mouse wheel+ modifier key and, mind you, that was a bug originally opened in 2002 (!) ... Mercurial commit that implemented the fix: https://hg.mozilla.org/mozilla-central/rev/63b547bb4078 So, pray tell, which was "every other version of firefox" ? Actually, that's quite an interesting story... Horizontal scrolling had been implemented in a perfect way by MCP in the previous PM platform, Tycho, forked off Mozilla ESR 38; New Moon 27.9.x, currently maintained by @roytam1, is built on Tycho ; HS in Tycho can be enabled by setting one of the "mousewheel.with_*.action" prefs to a value of 4. HS in Tycho works on both pages and frames; to test it on a page, zoom the page content until a horizontal scroll bar appears in the bottom of the tab; keep the designated key pressed and by simply moving the mousewheel, that bar should move, too... To test on a frame, just load https://www.bing.com in a tab and then have the bookmarks/history sidebar displayed (e.g. ctrl+B); increase the sidebar's width to the right, so that a horizontal scroll bar appears in the bottom of the bing tab... When PM was ported from Tycho to UXP, that feature (HS) regressed : https://forum.palemoon.org/viewtopic.php?f=37&t=20119 => https://github.com/MoonchildProductions/UXP/issues/732 => https://github.com/MoonchildProductions/UXP/commit/f0e053a However, Moonchild's fix was only partial, in that HS works in PM/NM28 for pages only, not frames; relevant UXP bug is still open: https://github.com/MoonchildProductions/UXP/issues/1173 will have a look later to see if I can fix it or not What you can obviously do is try whether UXP bug 732 (linked to above) applies cleanly in Moebius; of course, it would be just as partial, i.e. only apply on pages... IDK whether Mozilla bug 143038 is a better approach to the issue at hand... FWIW, legacy extension "Shift + Scroll (Horizontal Scrolling)" is available via CAA ("caa:addon/shift-scroll", originally over at AMO ); not tested ...

CTR is still available outside of the CAA extension (which is where you obviously obtained that direct link from ) in the author's GitHub repository: https://github.com/Aris-t2/ClassicThemeRestorer/releases If you're using the official Basilisk application on Win7+, then the latest CTR_v1.7.8.2019.10.27 is recommended; if, OTOH, you're using Serpent 52.9.0/55.0.0, then CTR_v1.7.8 is the last (EoS'ed) version for Serpent; the add-ons manager (AOM) is now different between Bk and St (Bk now uses PM's AOM with no support for WEs, while St retains FxESR52's AOM), Aris is currently maintaining CTR for official Bk (and classic Waterfox), only...

Ciao @resistor83 ; first thing I needed to do was get acquainted with PEC e-mail, since it's not used over here ; the following two links proved helpful: https://en.wikipedia.org/wiki/Certified_email https://vademecumitalia.com/pec-what-is-it-why-should-you-need-a-pec-address-and-how-to-get-one/ Now, I would strongly advise you to implement TLS 1.1/1.2 on your machine, regardless; probably better use the newer MS update, as per @erpdude8 : I can't see any way it could harm your existing setup; BTW, you did not say anything regarding Windows Updates in your system (only official Vista SP2 ones, till Vista EOL?) ... You specifically asked about Microsoft Outlook (part of Microsoft Office Suite), but, again, as pointed out by @Vistapocalypse, you neglected to tell about the used version... I am using myself the native e-mail client under Vista, Windows Mail, which, AFAIK, uses IE9's internet settings - I just checked the headers in the source of a gmail e-mail I received recently and I can spot the following (some parts obscured for privacy): Received: from mail-yw1-fxx.google.com (mail-yw1-fxx.google.com [209.85.xxx.xx]) by MX-IN-05.xxxxxxxx.gr (8.15.2/8.15.2) with ESMTPS id x8TKAo60027571 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) so I believe I can receive e-mails over TLS 1.2; but, of course, as detailed in this thread, IE9 supports only a limited number of TLS 1.2 cypher suites... Another solution for you to try on Vista would be the latest supported version of Thunderbird (52.9.1?) ... As for Microsoft Outlook, @Vistapocalypse is probably right; versions 2007 and 2010 use the WinHTTP library to connect to servers; Windows applications using WinHTTP on WinOSes < 10 can't normally use TLS 1.1/1.2, even if these protocols are enabled system-wide in the SChannel library, because WinHTTP is hard-coded to use only TLS 1.0. Mom (!) Microsoft decided to not mitigate this under Windows Vista (and Windows Server 2008) SP2, but did so for its Win7+ children (!) - Thanks M$! https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi Installation of that update should be followed by manually creating some registry keys, as instructed in the KB article; most sadly, an equivalent Vista/WS2008 update was NEVER released ... Some relevant articles (but fixes applicable only in Win7+): https://jaapwesselius.com/2018/09/23/outlook-2010-disconnected-with-tls-1-2/ https://www.ryadel.com/en/enable-tls-1-1-1-2-windows-7-8-os-regedit-patch-download/ https://www.greengeeks.com/tutorials/article/how-to-enable-tls-1-1-and-1-2-in-outlook-windows-7/ Illuminating SO answer regarding Vista: (from https://stackoverflow.com/questions/49497058/ ) Regards.

... But you haven't answered in the question kindly asked by @roytam1: Have you tried a fresh New Moon 28.8.0a1 profile (with no extensions) and try gmail behaviour there? In your screenshot (where NM28 is run under Win7) I see you have installed uBlock Origin (legacy), Disconnect and NoScript; they are bound to conflict with each other - also bear in mind that NoScript is explicitly incompatible with Pale/New Moon and UXP based browsers, so it's better to be avoided! IMHO, your gmail issues arise from using too many/incompatible content/script blockers. Second, you were told earlier (I think in the original thread) that you are not to compare latest versions of browsers (latest Chrome and Chromium based forks, latest Firefox Quantum/Browser) with the older-Firefox based forks in terms of behaviour on heavily-scripted sites; Google and the rest of the gang (e.g Facebook) always target the latest browser versions on new era hardware and OSes (and it can be argued that browser vendors have to always catch up with Google and gang in order to retain compatibility with whatever alpha Javascript/CSS features they are implementing on their sites) ... You only have yourself to blame for this "great" problem of yours... New Moon is mainly targeted for XP (and for the few of us on Vista), where official PM won't run; thus, XP+Vista users of NM won't ever be faced with the problem you've created... As for NM+PM on Win7 and higher, what you report is to be expected - don't use both browsers, as, of course, they'll share the same profile location - but, and this is worse, New Moon isn't anymore just PM for XP; the codepaths have diverged (and this is even more pronounced in the case of Serpent52/Basilisk52); e.g., the NSS library used currently by MCP in official PM is different to the one used in NM, so expect profile corruption to occur when the same profile folder is being alternatively shared by the two browsers. If you still insist on using both NM28 and PM28 on the same computer (and windows account), then you should be using the official Pale Moon Portable package, http://www.palemoon.org/download.shtml#Portable_versions so that New Moon maintains a discrete profile and PM28-portable another discrete one... ======================================== To cure your self-inflicted issues: 1. Uninstall official PM28 2. Back-up the corrupted NM28 profile, in order to salvage what can be salvaged from there... 3. Delete the original, old (saved elsewhere), NM28 profile. 4. Make sure you have the latest NM28 version, launch it and you should be in a new fresh profile - then start anew with configuring it the way you like - but heed to step 5... 5. Avoid installing too many blockers - ublock0-legacy alone would suffice. 6. When you're finished configuring NM28, exit it. 7. "Install" the portable version of official PM28 - that version should always be launched via the palemoon-portable.exe launcher (you can create a desktop shortcut for it) and with NM28 exited.

@-SnooPY-: Python 2.7.17 has been recently released: https://www.python.org/downloads/release/python-2717/ So, whenever it's out, v2.7.18 will be the EoL/EoS Python 2.7 release...

... I think they themselves stopped calling it that way ; recently, I had the chance to view the "about" box of latest stable Mozilla Firefox v70.0.1 (in sister's Win7 SP1 laptop ) and was surprised to see it was now referred to as "Firefox Browser"; any bet what it'll be called come v85.0 (I guess it'll make it there, as they'll be increasing major version numbers each month soon...) ?

Many thanks, finally ... and apologies for pestering you all night with this, it's just an OCD of mine to not get along well with half-baked solutions... For the curious: try { fp.isGoanna = (prefs.getCharPref("browser.search.searchEnginesURL").match(/(palemoon|basilisk)/) != null); if(!fp.isGoanna) fp.isGoanna = (prefs.getCharPref("app.feedback.baseURL").indexOf("palemoon") > 0); } catch(e) {} Have a fine new week!

Thanks @siria ; at least the second and third referenced prefs "kill two birds with one stone" (both NM28 & recent St52) : services.sync.syncKeyHelpURL;http://www.palemoon.org/sync/keyhelp.shtml services.sync.addons.trustedSourceHostnames;addons.palemoon.org,addons.mozilla.org but, sadly, leave out Serpent 55/Moebius: services.sync.syncKeyHelpURL;https://services.mozilla.com/help/synckey services.sync.addons.trustedSourceHostnames;addons.mozilla.org New snippet try { fp.isGoanna = (prefs.getCharPref("browser.search.searchEnginesURL").indexOf("palemoon") > 0); if(!fp.isGoanna) fp.isGoanna = (prefs.getCharPref("app.feedback.baseURL").indexOf("palemoon") > 0); } catch(e) {} will probably miss current Serpent 52.9.0/UXP, browser.search.searchEnginesURL;https://addons.basilisk-browser.org/search-plugins/ and (because of @Mathwiz's PRs): app.feedback.baseURL;https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-fork-targetting-xp/?do=getNewComment ... unless "palemoon" = "pale-moon" If the JS .indexOf function uses REGEX, perhaps it should just search for "moon" ? FTR, existing snippet will catch Serpent55/Moebius, app.feedback.baseURL;https://forum.palemoon.org/viewforum.php?f=61 unless, of course, that URL is also changed via a future PR...

Many thanks indeed for your swift response and efforts ; ... but I'm not in immediate need of the feature implemented, nor in a state to test its successful implementation myself, as I lack access to a SOCKSv5 proxy server with mandatory authentication; @Mabeso is the one to properly test that build, if he's currently reading this, he's kindly invited to test and report back ! ... So, no need anymore to keep the META-INF directory ; and, since it's not obvious by the current filename, it was originally the foxyproxy_standard-4.6.5 flavour of the extension... This is done, AFAICS, in the code below: try { fp.isGoanna = (prefs.getCharPref("browser.search.searchEnginesURL").indexOf("palemoon") > 0); } catch(e) {} Apologies if I get this wrong (as said multiple times, I can't code myself ), but I expect the above code to NOT WORK in the cases of Serpent 52.9.0 (Goanna 4.x.x) and Serpent 55.0.0 (Goanna 4.0.x), because, St52 => (by default) : browser.search.searchEnginesURL;https://addons.basilisk-browser.org/search-plugins/ and St55 => (by default) : browser.search.searchEnginesURL;https://addons.mozilla.org/%LOCALE%/firefox/search-engines/