VistaLover

My extensive tests contradict your reports! Using the very latest New Moon 28 package (32-bit on Vista SP2 x86) with a pristine NEW browser profile, and the "lazy-loaded" images of products (sport-shoes in your linked example) DO LOAD eventually, fully: and on a selected item's subpage: Proof of used browser: ... So, it is my educated guess that something on your side is breaking things I would first check with a new clean NM28 profile (like I did myself), and if you can't reproduce, then there's something in your customised profile (user-set prefs, extension-related changes, etc...) that causes this brekage... I would start with privacy related about:config settings and/or content blocking extensions (ad/script blockers, etc...) If, however, you can reproduce in a clean profile, then the culprit is system-wide (but you saying you can view the images with Serpent 52 pretty much rules that out...)... FWIW, the images are loaded from "*.rozetka.ua" domains, over HTTPS (TLS 1.2 in my case), e.g. https://i8.rozetka.ua/goods/17624553/puma_4062451528768_images_17624553343.jpg

Could you explain what this means? Is this a v28-only build preference Please read below: that's the accessibility libraries, official builds and my old builds used to have --disable-accessibility specified. I lost the build config and then it turns on that on compilation. ... and will go if I remember to do this. As to: I'm not currently using NM27, but do you now (i.e. in latest builds) see extraneous accessibility files inside its main directory? FWIW, one can always consult built-in pages like "about:buildconfig" to read build-time configuration flags...

Moonchild's stance is now "if the mountain won't come to Muhammad, then Muhammad must go to the mountain", as expressed (along with "name calling") below: https://forum.palemoon.org/viewtopic.php?p=200402#p200402 and further down in that thread:

Likewise on Vista SP2 32-bit :

With respect. this fact alone doesn't tell "us" anything useful, i.e. it doesn't contribute in the slightest towards identifying the exact cause of the issue reported in recent New Moon 28/Serpent 52 builds affecting you and several others... .... And, despite me having posted about it numerous times in the past, the Mypal fork is based on the release (stable) upstream branches of UXP+Pale Moon, while NM28 is based on the master (unstable) branches of UXP+Pale Moon (i.e. newer code; don't just let appVersion numbers fool you; arithmetic may dictate 28.13.1 > 28.10.2a1, but it's not the case code-wise); if that "bug" (probably connected to specific hardware setups and/or use of certain extensions) doesn't bite you yet in Mypal 28.13.1, it might when you later upgrade to Mypal 28.14.0 or later... IOW, switching to Mypal 28.13.1 from recent NM28 builds might be akin to @sal here downgrading his St52 copy to older buildID=20200904161558 What is unfortunate though is that our maintainer can't replicate it (yet?), so things for now look grim...

Thanks for building this time with the " --disable-accessibility" flag... I had commented: Upon testing, it appears that the latest Serpent 52.9.0 (32-bit) (BuildID=20200925161000) remains unaffected by that bug, which is, hence, only manifested in latest New Moon 28.10.2a1 (32-bit) (BuildID=20200925153118); but my initial assessment was correct - upstream commit https://github.com/MoonchildProductions/Pale-Moon/commit/9f56811e04ef4703aec82ba6a7c712e50c7667c0 was indeed the one that broke the native downloads manager... Moonchild became aware and later authored: [downloads] Correct and simplify host handling. https://github.com/MoonchildProductions/Pale-Moon/commit/fd30b23a0dfa2373539b348519aa9864976b46dd ... but, alas, it came too late for "us" , that one was not included in https://github.com/roytam1/UXP/commits/custom when latest NM28 was compiled... I have confirmed that the "fix" works as intended, restoring the functionality of the native NM28 Downloads Manager, as well as the functionality of the (legacy) Downloads Window extension several users (including yours truly ) have installed... I understand, your spare time allowing , that the fix will be included in next Saturday's released builds, in the interim I have taken the liberty of modifying and uploading a patched omni.ja file latest NM28 users could download to regain lost functionality: omni.ja https://www119.zippyshare.com/v/lAv8DFrY/file.html It should be placed inside "./palemoon/browser/" overwriting original omni.ja file (or you could rename/back-it-up first, e.g. as omni.ja.BAD) ; hope I've helped!

uB0-legacy now targets at least a Mozilla 45 compatible platform, so it remains compatible with FxESR 45, UXP-based browsers (NM28, Serpent 52.9.0), as well as Serpent 55.0/Moebius, but compatibility with Tycho-based browsers (NM27) is, sadly, lost... The very last stable version that is compatible with NM27 is 1.16.4.21 : https://github.com/gorhill/uBlock-for-firefox-legacy/releases/tag/firefox-legacy-1.16.4.21 I prefer myself uB0 to the AdBlock Plus family of content blockers (not least because the latter consume far more RAM), but it is true that v1.16.4.21 will remain onwards in an unmaintained state, while, OTOH, several useful filter lists now target recent versions of content blockers and, as such, employ more recent code formats/syntax that, unfortunately, the combination of NM27+uB0-1.16.4.21 can't cope with any more... So expect, over time, uB0-1.16.4.21 to become less efficient in its designated blocking tasks... I don't use myself NM27 quite often, but when I do (and for the specific sites I visit with it), uB0-1.16.4.21 serves me well for the time being...

@roytam1 : About the (native) Downloads library window (pop-up) being broken (which takes with it the Downloads Window extension), I'd start by taking a look at: https://github.com/roytam1/UXP/commit/68ed744bb6052300e9b769c4b73570c2f22b6362 https://github.com/roytam1/UXP/commit/f8c9d784db842be0969c2f7e79eb29b40e519696 Perhaps upstream have inadvertently broken it, they have yet to produce official builds (unstable PM, Basilisk) with the changes merged-in, so no-one on their community is able to report the breakage currently...

Starting last August, the WSUSscsn2.cab file is being signed by M$ ONLY with a SHA-2 code-signature, high chances are it won't work with WUMT under XP ; it certainly chokes here under Vista SP2:

The same stands true also for Vista updates currently hosted at WU SHA-2 endpoints; that project I mentioned simply enables connection to the endpoints, M$ could purge Vista related content at anytime... ... and I'm sure Microsoft will use all their powers to hunt down and "terminate" such public WU alternatives...

And, just out of the blue: ????????

Thanks for the info, @Dave-H Someone over at Microsoft must have (temporarily, I bet... ) turned back on the SHA-1 endpoints for Microsoft/Windows Update, perhaps solely for the sake of delivering these last few Office 2010 updates on XP/Vista users ... I can also confirm that WU[SHA-1] is currently (Sept 26th 2020, ca. 01:35 UTC) back on Vista SP2 32-bit: Since I have installed SHA-2 support last October, I am currently on Vista build 6.0.6003; hence, I get offered nothing by MU/WU (but, OTOH, I don't think I have anything missing as far as Vista SP2 up-to-EoS [April 2017] updates are concerned... ) ...

@dencorso: You probably missed reading ... and the 3 following posts (exchange between me and @Vistapocalypse ), especially this: Historical progression of facts: 1. WD/MSE on Vista stopped being update-able directly from Windows Update (or via their integrated [manually] "Check for Updates" feature [which also evokes WU]) in the start of July 2019, when Microsoft changed the WU delivery infra to employ only SHA-2 endpoints (the SHA-1 ones were still on-line at the time...) 2. WD/MSE users on Vista had to turn to manually fetching files (for 32-bit OSes) mpas-fe.exe/mpam-fe.exe and running those to get the definitions of their M$ antispyware/antimalware "solution" up-to-date; these standalone files (links of which can be found on http://www.microsoft.com/en-us/wdsi/defenderupdates ) were, at the time, still dual-signed (i.e. both SHA-1+SHA-2 code signatures), so running them and installing updated defs was working.... 3. Towards the middle of October 2019, M$ stopped dual-signing those files (as well as their "ingredient" files), updated versions came as only SHA-2 signed; while running an SHA-2 only signed file is not necessarily a problem on Vista SP2 patched fully until its EOS (April 2017), it is in this case because the security app/OS has to verify the integrity of both the engine and updated definitions, before installing/integrating them... Without SHA-2 support in the OS, definitions for both WD/MSE would stay at their last dual-signed version and become stale in a few days... For posterity, the last dual-signed version of the off-line updaters was v1.303.1946.0, sharing the same mpengine.dll v1.1.16400.2 ... 4. To overcome [3], Vista SP2 users had to manually download and apply some KBs, targeting Vista's Server counterpart, WS2008, which bring SHA-2 support to the Vista OS; with that implemented, mpas-fe.exe/mpam-fe.exe [SHA-2 only] could properly update off-line their respective M$ security apps... NB: While the finer details were not very clear then, installing those SHA-2 enabling M$ updates on Vista has the following shortcomings: 4.1. Vista's Windows Update Agent (wuaueng.dll) is not being updated to its SHA-2 compatible version (M$ made it sure, via checks, that only the supported WS2008 SKUs got that privileged treatment, not poor EoS'ed Vista , despite them both sharing NT 6.0) , so connection to the new SHA-2 only Windows Update endpoints was/is not feasible; hence, WD/MSE could not connect to WU and be updated, again, via that route (as in the era before July 2019) ... 4.2. Vista's build number is changed to 6.0.6003 (SP2 = 6.0.6002) and that fact by itself made the WU SHA-1 endpoints give it the cold shoulder (this is OT in this discussion, but if available dual-signed Vista updates were not installed prior to the migration to SHA-2 support, these would no longer be offered via WU[SHA-1] 5. On the first week of August 2020, M$, as announced, shut down permanently their WU SHA-1 endpoints, cutting off completely Vista SP2 (with/without SHA-2 enabled support) and, I'm sure you know already, WinXP This had, of course, no bearing on either WD/MSE on Vista, but is at least related to this thread's title... 6. Closing in on recent times, v1.321.xxxx.0 was/is the last Vista compatible series of offline security updates (i.e. files mpas-fe.exe for WD & mpam-fe.exe for MSE); that series introduced engine file (common for both installers) mpengine.dll v1.1.17300.4; the last version in that series was 1.321.2290.0, released on Aug 28th 2020: Next series of off-line installers,1.323.xxxx.0, introduced new engine version 1.1.17300.5, but that one is no longer compatible with Vista/NT6.0: So Vista SP2 (with SHA-2 support installed) users of either WD/MSE can't manually update their definitions past v1.321.2290.0 (close to a month stale as it is...) M$ continue to advertise on their "Security Intelligence" () portal that they offer off-line updaters for "Windows Defender in Windows 7 and Windows Vista", and in fact I have sent them feedback informing them of the current predicament Vista users find themselves in, but they have yet to respond to my report... BTW, next series v1.325.xxxx.0 is closing in... PS1: There have been reservations expressed by members here, notably @Vistapocalypse, about the efficacy of running Vista's native WD or a considerably old, nag-free, version of MSE on Vista, and probably with good justification ... But this is NOT the gist of this post; so please refrain from such remarks here... PS2: As of this writing, I have employed a "hack" to keep updating my WD with defs past Aug 28th, which essentially boils down to keep using the last compatible engine, v1.1.17300.4, with definitions (files *.vdm) prepared for the non-compatible engine 1.1.17300.5; for now, it seems to just work; but the two engine versions are close enough/similar; I bet when a future engine version is released, say 1.1.19xxx.0, the new definition files it will come with won't be backwards compatible with v1.1.17300.4 - it'll then be GAME OVER! PS3: I haven't yet jumped into @win32's Extended Kernel, especially since I'm on a physical machine (so not on a VM I can experiment with), but also because I am on 32-bit, which presents special challenges towards the ExtKernel goal... If @win32 has already implemented TryAcquireSRWLockExclusive in his kernel32.dll wrapper, then that would be the ultimate solution for Vista users wanting to keep their WD/MSE installation updated with current definitions/engine! PS4: A new project has come to light (first mentioned here by @burd ) that restores WU[SHA-2] support to Vista SP2 past last August's breakage; the legality of that project is still unclear; also unclear is whether WU connection is being restored to either WD/MSE, so that the apps could (again) download updated definitions directly from WU (Vista Extended Kernel would be required for successful installation...). I guess that's it!

That test page is no longer valid, as pointed out by its webmaster himself: (and IIRC, that matter has been reported in detail previously in this thread; I just don't have the time at this moment to find that post...) Just use another test page to verify h.264 browser support... I don't think the CDM is downloaded automatically anymore, one has to download and install manually; some differences may be present between Fx 49 & Fx 52; just consult again, being perhaps more attentive, first post of this thread... Others may chime in with more current details, if any...

With great respect, we aren't/shouldn't be doing that here... TL;DR: Previous upstream unofficial branding name for Pale Moon forks: New Moon Updated (by upstream) unofficial branding name for Pale Moon forks: Browser

... Though the author himself, in a red-lettered top notice, recommends instead to migrate to his more current utility, WinUpdatesView (v1.13) ...

I'm sorry to admit that the above expectation borders with Utopia... The general consensus on "their" camp seems to be that "we" are in essence practically stealing code "we" were never meant to lay "our" hands on, that "we" are just acting selfishly, full of entitlement... I think that part was explained previously by M.A.T; hosting the source code of one project covered by MPL-2 in a private repo does not make it Closed Source; whenever the code author releases an executable form (binary) of the code, he has the obligation to provide, by reasonable means, access to the source code that was used to compile the executable form; "reasonable" means could very well be a link to a source tarball or, upon user request, dispatch of the used source via a physical storage medium (the cost of which should be covered by the user requesting it...); what's more important is the fact that the publicly revealed source code does not carry the "buildability" obligation, that is any additional "hack" used by the author to compile the source into an executable form can remain private... I see this discussion (here in this thread) quickly exploding, again, to Rebranding Roytam1's browser offerings ; so I agree with @TechnoRelic that any additional content to that end be posted in the existing specific thread, not here... My initial comment here was to highlight the fact the unofficial Pale Moon branding (upon which NM28 is built) has been changed upstream but not adopted by "us", and the eventual ramifications (if any) that decision (by "our" maintainer) may entail... I hope it's clear now...

... And this is something we've all been informed about... I'm sure it will be acted upon when convenient...

I'll remind people here that I'm not actually an authority on Google Chrome and Chromium derived browsers, having been from the very start a Mozilla Firefox user, first (2005-2008) on a WinXP desktop and then (2008-2018?) on this Vista laptop... This is to clarify that I haven't followed closely Chromium's development during that era... I've learned quite a few things from XP users of Chrome 49, and it's true that specific [old] version (officially the EoS one for XP/Vista) does rely on OS resources/libraries for secure connections (which involve both available TLS protocols and available cypher suites). Contrary to what Google (the No.1 enemy of the Vista OS, by far ) believed, WinVista != WinXP, so having a fully updated Vista SP2 OS with TLS 1.2 support will grant you more accessible websites using Chrome 49 on Vista, thanks to Vista supporting more cypher suites by default and, on top of that, having SNI support that WinXP lacks... But all this is probably a moot point already, because Chrome 49's rendering engine is antiquated by now... To conclude, yes, Chromium 49 can only go up-to TLS v1.2 on an updated Vista system (with KBs targeting WS2008 originally ) At some point further down its development, Chromium disengaged to a degree from OS libs where TLS support is concerned, so that Chromium 57/58, upon which Yandex Browser (YB) 17.4/17.6 builds, comes with bundled/native support for the TLS protocol. I haven't used YB 17.6 (portable) here for many months, having long ago switched, first to 360EE v11 (Chromium 69 based), then to 360EE v12 (Chromium 78 based) and currently testing (beta channel of) 360EE v13 (Chromium 86 based). YB 17.x has other significant shortcomings by now, affecting Google Web Store (GWS) support , but that is part of a future post about YB 17.x ... By default, YB 17.6 supports TLS 1.0+1.1+1.2, provided by its own (Chromium) libs (i.e. non-dependent on OS TLS support, kinda like Firefox); but there is latent TLS 1.3 support, too, which can be enabled via a browser flag; The problem is that YB 17.6 was released at a time when TLS 1.3 hadn't been finalised yet, so it only supports a TLS 1.3 draft preceding the final one (i.e. RFC8446) Testing on dedicated TLS testing sites you get mixed results, depending on whether the test site detects pre-final TLS 1.3 drafts or not; SSL Labs client test picks up pre-final TLS 1.3: ... but Browserleaks ... and pinterjann DO NOT! As a closing note, if you want to disable lower, deemed currently insecure, versions of TLS, you can launch YB via a shortcut containing the following flag: --ssl-version-min=tls1.2 or --ssl-version-min=tls1.1 if you want to disable just TLS 1.0 ...

The last release channel version of WSUS Offline with Vista support was v10.9.2, released on 2017-03-19; the last release channel version of WSUS Offline with WS2008 support was v11.8.3, released on 2019-11-14. Vista users should probably use the ESR channel of WSUS Offline; the last/most recent version advertised on their download page with any Vista support is v9.2.5, released on 2019-06-04: https://download.wsusoffline.net/ => Archive However, there's still a more recent v9.2.6, not being publicly advertised, released on 2019-11-08: https://download.wsusoffline.net/wsusoffline926.zip

... My thoughts exactly!

Thanks for the explanation! How do you intend on pursuing this? Will you be going back to a --disable-accessibility build config flag for your future NM28 builds, continue as things stand now or is this simply now out of your control? ... OK then, pretty much as I had it figured out myself...

Let me begin by thanking you for continuing to deliver updated builds of your browsers, despite the recent major hardware hardships... (pun intended! ) Starting with last weekend's New Moon 28 package (linked-to above) and including this weekend's latest NM28 offering, I've noticed that 3 compiled files, all previously associated with Serpent 52.9.0 builds, have somehow slipped into New Moon's main app directory; these files are: Accessible.tlb AccessibleMarshal.dll IA2Marshal.dll I browsed quickly your custom UXP branch and did not find any clues there as to why these 3 files now appear inside NM28's main appdir ; if it's any info, these 3 files also do not appear inside upstream official compilations of Pale Moon 28.13.0/29.0.0a6; but since our fork has deviated somewhat from upstream, that fact may or may not be relevant... Mentioned files, as pretty much expected, continue to reside inside Serpent 52.9.0's main appdir (as well as in upstream official Basilisk 52.9.2020.09.11 ) Now, as a test, I went along and deleted those 3 "errant" files and latest New Moon 28.10.2a1 32-bit (buildID=20200918232718) launches and runs fine here (Vista SP2 32-bit, build 6.0..6003) without them... It looks as if those files are generated via a first stage Serpent/UXP compilation and are then added, by mistake, with other compiled files that are common/shared with the New Moon 28/UXP compile/build (possibly to expedite compilation of both UXP browsers...); if that's by design (and may I note that this wasn't the case with the previous [now lost] building environment), perhaps it would be best to remove those 3 unneeded (for NM28) files post compilation and prior to packaging/uploading... https://github.com/MoonchildProductions/UXP/issues/1653 Clean up Windows widget code https://github.com/MoonchildProductions/UXP/commit/6f5cd8a [widget] Clean up Windows widget code some. Can you please elaborate a bit why upstream UXP#1653 was not merged? Would it have broken WinXP compatibility if it had? Being on Vista here (NT 6.0), could this have been handled slightly differently if it provides performance improvements on Vista+? (e.g. ifdef'd to load the code under Vista+ but not under XP?) Apologies if I'm asking something that can't be done... I'm really sorry to have to bring this up, but don't you expect "upstream" to hear about that? You are, at the end of the day, still building "unofficial" Pale Moon builds and upstream have modified that branding (which is their prerogative, it appears...). I won't pretend I understand fully the Open Source licensing schemes, but I smell (additional) trouble coming from upstream, this time from Moonchild himself With all said and done (and undone) in the past, I'd hate to witness any further escalation between "us" and "them", especially if it results in more restrictive action(s)/sanctions from upstream... What do others think on this? Finally, I don't use any of these forks myself, but out of pure (healthy) curiosity, what source do you actually use now to produce updated builds of? AFAIAA, upstream have moved to a private repository, so are you now just updating the platform (UXP) submodule/component, which is still public? Thanks for all your hard work and efforts , thanks in advance for any answers received... Best greetings

MSE offline definitions file (mpam-fe.exe) and WD offline definitions file (mpas-fe.exe) both share the same engine, file mpengine.dll (currently at version 1.1.1730.5); no need to wonder anymore...

YES