VistaLover

... Even if the "issue" can be reproduced using official Interlink on a sanctioned Windows OS version and even if the "issue" is acknowledged as a genuine bug by M.A.T. (one person's "unfathomably unacceptable" could very well equate "take it or leave it" in M.A.T.'s universe ) and even if the bug is fixed, the fix will arrive to the reporting user only in binary form, via a future Interlink build release ; i.e., the Binary Outcast source code repository being private, the fix in source code form (commit) won't be public, thus not portable to the fork (Mail News) in a straightforward fashion... @Dylan Cruz: Do you now see the broader picture?

...Well, @roytam1 is extremely busy and pressed for time currently in RL, that's probably why the recent discussion about broken YT chat on LIVE streams was not acted upon in a due fashion... Upstream have also received similar reports (be it in the Mac subforum) and Moonchild himself was initially oblivious to the solution: Most thankfully, @rereser stepped in to enlighten the browser guru: https://forum.palemoon.org/viewtopic.php?p=201384#p201384 so I guess that change will soon hit the upstream Pale Moon repo and, hopefully, be merged in next weekend's New Moon 28 builds... NB: As an unofficial/non-endorsed fork, New Moon isn't entitled access to the "Dynamic SSUAO Updates" service, currently put in place for the stable channel of Pale Moon; so, as you said, a NM28 user has to manually correct/modify the YT SSUAO entry inside about:config... OT: Thank you again for notifying "upstream" about this; I guess having an account on both "camps" is useful for cases like this one, where both "worlds" can profit from... But it sure was a prudent thing to exclude even the most minute reference to forks/officially unsupported OSes/MSFN in particular, or a "certain" person will have eaten you raw... (And I've also noticed how that person has adopted a recent habit of checking official forum posters against the database of MSFN members, once a match is found (via username), then the reporter is treated as dirt... ) Kind regards

Many thanks for still finding the time, between your hectic real life currently, to compile and offer these builds! I think I am one of the very few (possibly the only one?) but I actually read closely and study these official changelogs every week (so rest assured your effort is not in vain...), but I am sorry to say this week's is a sorry mess... And this is identical to last week's: I believe the correct changelog for this week is (what is currently listed under this week's PM changelog): Official UXP changes since my last build: - Issue #1665 - Take overflow-wrap into account when calculating min-content intrinsic size. (8e18743ab) - Issue #1666 - Implement overflow-wrap: anywhere (dadef50bd) - [devtools] Teach devtools about overflow-wrap: anywhere (521f2b476) - Issue #1606 - Add support for multi-monitor DPI awareness v2 (W10 1706+) (bda6f1a93) source: https://github.com/MoonchildProductions/UXP/commits/master Correct changelog for this week is: Official Pale-Moon changes since my last build: - Back-end branch pointer update (Unstable 2020-10-04) (f6ae5e0) - [app update] Move update cert entries to branding (b48aee5) - Issue #1812 - Enable per-monitor DPI v2 in Pale Moon (762408f) - [SSUAO] Update Yahoo override, since they now throw a fit when seeing anything "Pale Moon" in the UA. (aa3ff77) source: https://github.com/MoonchildProductions/Pale-Moon/commits/master NB: http://rtfreesoft.blogspot.com/2020/10/weekly-browser-binaries-20201010.html is also messed up!... Take the best of care!

Let us hope the official UXP/Basilisk repositories remain public, so that any future purging of 32-bit-only codeblocks could be reverted... Nonetheless, successfully compiling the source for x86 targets will turn, over time, into an increasing challenge, since upstream won't test anymore whether their codebase compiles into 32-bit binaries, nor would they offer any kind of help to mitigate eventual future 32-bit compilation errors...

@Alex654 : I just navigated to a LIVE youtube stream: https://www.youtube.com/watch?v=DDU-rZs-Ic4 with the very latest New Moon 28 32-bit build (buidID=20201002092931) and live chat is displayed correctly: My yt SSUAO currently is general.useragent.override.youtube.com;Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) I can confirm that by restoring the default yt SSUAO: general.useragent.override.youtube.com;Mozilla/5.0 (%OS_SLICE% rv:60.0) Gecko/20100101 Firefox/60.0 PaleMoon/28.10.2a1 "Live Chat" BREAKS, as you reported:

This is a known issue that has already been reported in the "upstream" support forum, as it is reproducible in official Pale Moon client (v28.1x.x): https://forum.palemoon.org/viewtopic.php?f=70&t=25154&p=198725 Last post from OP (a month ago) suggests a youtube.com SSUAO mimicking a Fx 62.0+Basilisk UA, e.g. Mozilla/5.0 (Windows NT 6.1; rv:62.0) Gecko/20100101 Firefox/62.0 Basilisk/52.9.2020.10.05 fixed things for him at the time... NB: Just a friendly reminder , when you seek help for an issue affecting specific sites/services, be kind enough to also provide clear URLs where the issue reported can be tested by other members of this community who may not be familiar with the issue at hand (FWIW, I don't have a Google/YouTube account and I NEVER use the "chat" feature ) ... Best greetings

Hello there @feodor2 That code was probably ported from Arctic-Fox, a Tycho (Pale Moon 27's platform) fork targeting mainly old Macs: Part1: https://github.com/wicknix/Arctic-Fox/commit/9e6e13a15ae60fc4379b9dd0dd26969784b13a53 Part2: https://github.com/wicknix/Arctic-Fox/commit/bc40f1eb67037a878c0b270f72efb3076cfcf01e That code there affects only FFmpeg's h264 decoder but, by the looks of it, is turned OFF by default; you'd have to create the hidden about:config boolean pref: media.ffmpeg.skip_loop_filter and set it to true to make use of it... I can't speak from experience, because under Vista SP2 32-bit I'm not seeing (rather... hearing ! ) this bug ; but having followed closely related discussions in the past, I can surmise that: Twitter don't care at all for a Pale Moon user-agent (or any other non-mainstream browser they don't support ), so they are treating it as a generic mobile device browser, thus feeding it with a lower quality/bandwidth audio stream encoded in the HE-AAC (v1/v2) profile (more here); most times, they stream using either AppleHLS and/or MPEG-DASH (i.e. fragmented streams), rather than progressive download streams; the ffvpx library patch (to contain additional h.264/aac decoding support) is just a hack to cater to Windows XP's lack of Windows Media Foundation (WMF), i.e. native patented decoders; it hasn't been identified, yet , where exactly things break, but the patched ffvpx can't cope fully with HE-AAC over fragmented (aka adaptive bitrate ) streams, hence the audio distortion under XP (NB: On Vista+, NM28 makes use of WMF decoders [media.wmf.enabled;true] and this issue does not manifest itself... ). Switching to Firefox compatibility UA-mode (or using a Firefox SSUAO for twitter.com) allows Twitter to treat NM28 as a desktop browser and thus it is fed audio in the higher quality/bandwidth AAC-LC format (and possibly via progressive HTTP streams) that ffvpx can decode more efficiently... But YMMV, especially between various sites... Kind regards

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