VistaLover

... Perhaps you're referring to the fact Adobe Flash Player had been the last NPAPI plugin for which Firefox support was removed (whereas support for other NPAPIs like PDF/Java/WMPlayer/etc. was axed quite earlier...) ? ... But, does it show up on package "palemoon-27.10.0.win32-git-20210904-d43e6f58e-xpmod.7z" and earlier builds? I think there are two related bugs here: 1. The "plugin icon" (what I called "plugin permissions control icon") not showing up in the left extremity of the URLbar (which, according to my test, precedes package "palemoon-27.10.0.win32-git-20210911-8d7b56d38-xpmod.7z"), and 2. "Ask-to-Activate" as a whole not working at all, which, as you said, manifests itself starting with package "palemoon-27.10.0.win32-git-20210911-8d7b56d38-xpmod.7z" ...

Hi ; long time, no see (at least in this thread ...); well, what is it to be startled by? I, since long ago, consider Firefox Browser (as in post Firefox Quantum) to be a Chromium fork of sorts... Sure, Firefox 93.0 can open docs.microsoft.com pages without issues...

I tested this with Adobe Flash Player v34.0.0.192 (set to "Ask to Activate") and the official test page: https://get.adobe.com/flashplayer/about/ While I can indeed confirm the findings reported by RainyShadow in latest NM27: 1. No Flash frame is displayed at all 2. The plugin permissions control icon is missing at the beginning of the URL bar , I'm afraid the "Ask-to-Activate" feature has been partially broken even before BuildID=20210910040612 (package "palemoon-27.10.0.win32-git-20210911-8d7b56d38-xpmod.7z"); e.g., with BuildID=20210903005445 (package "palemoon-27.10.0.win32-git-20210904-d43e6f58e-xpmod.7z") I get this: i.e. the "plugin" icon in the URL bar is still gone, and the grey Flash frame doesn't display the prompt to "Activate Adobe Flash"; for comparison, here's how latest St52 behaves:

Below screengrab is from a visit to linked article in my dirty St52 profile: As I already wrote, M$ want you to use [Chr]Edge on their sites...

https://docs.microsoft.com/ defaults to https://docs.microsoft.com/el-gr/ here , and the page does load in latest Serpent 52.9.0; for the rest of you not able to read Greek , the equivalent English page is: https://docs.microsoft.com/en-us/ The SyntaxError reported is still there, but refering to a different "*.index-docs.js" script ; what doesn't work is the searchbar on top of that page, because when you hit "Search", it redirects to https://docs.microsoft.com/el-gr/search (or https://docs.microsoft.com/en-us/search ) which is loaded blank , except for a footer; again, responsible is a SyntaxError in a different "*.index-docs.js" script... Incidentally, I only recently mentioned the https://docs.microsoft.com/en-us/search "issue" in the 360EE thread, ... 'T is the way Google Chrome devs want "things" to work now: ONLY in the latest version of THEIR browser (and forks of...); WWW? Nah, WWD (=dictatorship)... But this discussion belongs elsewhere....

Thanks for the additional feedback... If I were to follow fully @ArcticFoxie 's way-of-doing-things, and let it be documented I have ZERO OBJECTION against, I should feel elated that I can load https://docs.github.com/en/rest/* URIs in both 360EEv11/v12 via blocking (in uBO) ALL scripts originating from "docs.github.com", without any perceivable dent(s) in the pages' expected performance ... However, the little sleuth in me wants my previous query answered: After some trial-and-error, it turns out the sole script responsible for the final page blank-out in said browsers is https://docs.github.com/_next/static/chunks/webpack-af28476a2e7790fd48db.js Blocking just the above script is sufficient for GitHub Docs pages to render fully in 360EEv11 (Ch69-based) and 360EEv12 (Ch78-based); in uB0, I just created the following static filter: ! https://docs.github.com ||docs.github.com/_next/static/chunks/webpack-af28476a2e7790fd48db.js$script,domain=docs.github.com "and whoala" :

Thanks for testing! Unfortunately, I don't use NoScript (is this the one you're using?), nor am I inclined to install it for the sake of just this site... However, your input has been much appreciated ; I think I've achieved a similar effect by denying "scripting" on "docs.github.com" via uBO: and, e.g., https://docs.github.com/en/rest/overview/api-previews loads now in 360EEv12 just fine ! uBO's logger shows that a total of 12 scripts are being blocked, so my understanding is that one (or more) of them are incompatible with the JS engines of 360EEv11/v12 (but compatible with 360EEv13) ...

I am unable to fully load GitHub Docs in both 360EEv11 and 360EEv12 ; https://docs.github.com/en/rest/reference/repos ... begins to load in an apparent "normal" fashion (it's a rather "elongated" page), but - just before load completion - it blanks out in the end! I have tried in both browsers to use a clean/fresh profile without any extension, but the issue persists ; the javascript console isn't telling much... The page eventually loads fully in 360EEv13 (and, FWIW, in latest St52+gh-wc-p), but if there's some workaround to enable it on either v12/v11, I'd much prefer it over v13 (v12 and, especially, v11 are much more "fluid" in this 13-yr old Vista laptop ) ... FTR. another Microsoft-owned page that demands at least 360EEv13 is Microsoft Docs Search : https://docs.microsoft.com/en-us/search/ ; I feel it's no coincidence either... I'm quite certain that after M$ adopted Chromium as the basis for their re-incarnated Edge Browser, they're making absolutely sure pages they have control on are fully working only on recent/latest Chromium-based browsers...

http://web.archive.org/web/20201209013928/https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Working_with_multiprocess_Firefox

The documentation was removed last December: http://web.archive.org/web/20200801000000*/https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Working_with_multiprocess_Firefox Relevant articles: https://blog.mozilla.org/addons/2016/08/02/multi-process-firefox-and-add-ons-a-call-to-action/ https://wiki.mozilla.org/Add-ons/developer/communication#Migration_paths_for_developers_of_legacy_add-ons https://extensionworkshop.com/documentation/develop/comparison-with-the-add-on-sdk/ I'm quite sure additional documentation has been spared from Mozilla's axe, it's just that one needs to hunt it down with determination...

As I stressed already, GitHub pages do load when e10s is force-enabled in St52, but the gh-wc-p extension isn't e10s-compatible; this means that the majority of useful functions (especially for a logged-in user) in the GitHub web front-end simply fail to work... Read the relevant discussion over at https://github.com/JustOff/github-wc-polyfill/issues/33

Technically, they're being distributed by Zhongcheng, the exclusive and official distributor of Adobe Flash Player (in mainland China): The form of distribution has shifted recently to an AIO executable called Flash Center: https://www.flash.cn/english (links to FlashCenter_Setup_1.0.6.43_silent_10001.exe) Individual plugin installers (be it only stub, i.e. on-line) are linked on: https://www.flash.cn/download-wins but unsure whether they'll be phased out completely, in favour of Flash Center... Due to the spyware nature of these Chinese Flash products, several recent filter lists (e.g. inside uBO) will flag "www.flash.cn/*" URIs as malicious and block them from loading in the browser...

34.0.0.192 works fine in 360EEv12 under Vista SP2 32-bit: No nags whatsoever...

And, as far as upstream are concerned, the same stands true for the remainder of this month and the first week of November: https://forum.palemoon.org/viewtopic.php?p=220767#p220767 http://developer.palemoon.org/docs/release-engineering/ Pale Moon Version - CLOSED TREE - Intended Release Date - Type of Release 29.5.0 2021-11-02 2021-11-09 Major/Feature Release

That fetches a .CSV file, inside which: ia64 Windows Server 2008,,,,,,, File name,File version,File size,Date,Time,Platform,SP requirement,Service branch Hal.dll,6.0.6003.20489,"428,264",21-Mar-19,1:32,IA-64,None,Not applicable File name,Ia64_hal.inf_31bf3856ad364e35_6.0.6003.20489_none_0726f69c1b902d52.manifest,,,,,, File version,Not applicable,,,,,, File size,"1,655",,,,,, Date (UTC),21-Mar-19,,,,,, Time (UTC),3:40,,,,,, Platform,Not applicable,,,,,, x86 Windows Vista,,,,,,, File name,File version,File size,Date,Time,Platform,SP requirement,Service branch Halacpi.dll,6.0.6003.20489,"137,960",21-Mar-19,1:53,x86,None,Not applicable Halmacpi.dll,6.0.6003.20489,"169,704",21-Mar-19,1:53,x86,None,Not applicable File name,X86_hal.inf_31bf3856ad364e35_6.0.6003.20489_none_072552a61b922456.manifest,,,,,, File version,Not applicable,,,,,, File size,"2,244",,,,,, Date (UTC),21-Mar-19,,,,,, Time (UTC),3:57,,,,,, Platform,Not applicable,,,,,, x64 Windows Vista and Windows Server 2008,,,,,,, File name,File version,File size,Date,Time,Platform,SP requirement,Service branch Hal.dll,6.0.6003.20489,"230,632",21-Mar-19,1:41,x64,None,Not applicable File name,Amd64_hal.inf_31bf3856ad364e35_6.0.6003.20489_none_6343ee29d3ef958c.manifest,,,,,, File version,Not applicable,,,,,, File size,"1,656",,,,,, Date (UTC),21-Mar-19,,,,,, Time (UTC),4:15,,,,,, Platform,Not applicable,,,,,, So, though not specifically mentioned, the KB does update HAL related files to v6.0.6003.20489

This is just a guess, but since I see no sse/ia32 part in the package's filename, I suspect it's been compiled to expect at least SSE2...

... YES; remove the LAV dlls adjacent to basilisk.exe, exit browser, relaunch browser and test: http://demo.nimius.net/video_test/ https://tekeye.uk/html/html5-video-test-page http://camendesign.com/code/video_for_everybody/test.html http://www.html5videoplayer.net/html5video/mp4-h-264-video-test/ https://ophi.org.uk/test-html5-video/ These DLLs have been updated by roytam1 on Sep 25th, 2021 ; they are based on FFmpeg 3.4.9 Those were based on FFmpeg 3.1.1 What does that even mean? What type of CPU are you on? If it supports SSE2 instruction set, download the default package; if it supports up-to SSE, download the ia32 variant; for even older CPU, give the noasm variant a try... The links are for the 32-bit architecture; the extracted DLLs must be placed adjacent to palemoon.exe (for NM27) / arcticfox.exe (for ArcticFox-Win); the browser has to be restarted to successfully load the DLLs...

... Serpent 52.9.0 on WinXP doesn't rely on LAV dlls for h264/aac decoding (i.e. playback); it uses a modified ffvpx third-party library; just make sure media.ffvpx.enabled is in its default value of true (FWIW, under Vista SP2 and higher, St52 defaults to using WMF system - OS - codecs; it can be configured to use ffvpx there, too, by disabling media.wmf.enabled; do note that ffvpx doesn't use H/W h264 decoding (Win7+), if your gfx card supports it, that is...). TL;DR: You should remove LAV dlls from within the Serpent 52 application directory! LAV dlls for NM27 (and related forks) were recently updated: https://o.rthost.win/palemoon/lav-dll-lite-3.4.9.7z https://o.rthost.win/palemoon/lav-dll-lite-ia32-3.4.9.7z https://o.rthost.win/palemoon/lav-dll-lite-noasm-3.4.9.7z Download the variant that is compatible with your CPU...

Clean Flash Installer repo moved, for now, to GitLab: https://gitlab.com/cleanflash/installer/-/releases/34.0.0.192 If Adobe are really determined, the future of that second repo might also be uncertain... PS: If on WinXP, to load that GitLab page you need a UXP browser by roytam1, along with the very latest version of github-wc-polyfill extension by JustOff; any flavour of 360EE will also do...

Web Archive scavenged links to CleanFlash_34.0.0.192_Installer.exe : https://web.archive.org/web/20210923173744/https://github.com/CleanFlash/installer/releases https://web.archive.org/web/20210923173709/https://github.com/CleanFlash/installer/releases/tag/v1.5 https://web.archive.org/web/20210923173709/https://github.com/CleanFlash/installer/releases/download/v1.5/CleanFlash_34.0.0.192_Installer.exe

The latest release of CleanFlash_34.0.0.xxx_Installer.exe WAS based on Chinese Flash v34.0.0.192 ; I wrote "WAS", because https://github.com/CleanFlash/installer An issue has been filed: https://github.com/darktohka/clean-flash-builds/issues/4

@roytam1: https://forum.palemoon.org/viewtopic.php?p=220472#p220472 https://www.basilisk-browser.org/releasenotes.shtml http://archive.palemoon.org/source/basilisk-2021.09.27-source.tar.xz Have the above been taken into account already? Thanks for all you do for these communities here!

Evil Microsoft have removed that package (VCForPython27.msi) last April (2021) ... Fortunately, WebArchive have salvaged it below: http://web.archive.org/web/20210414074322/https://www.microsoft.com/en-us/download/details.aspx?id=44266 http://web.archive.org/web/20210106040224if_/https://download.microsoft.com/download/7/9/6/796EF2E4-801B-4FC4-AB28-B59FBF6D907B/VCForPython27.msi Digitally signed (SHA1, WinXP compatible) on Sep 29th, 2014 ...

... Hopefully the following indispensable Chrome extension https://chrome.google.com/webstore/detail/get-crx/dijpllakibenlejkbajahncialkbdkjc will continue to work as designed in the "ungoogled" flavours... I use it routinely to manually download and archive .CRX files directly from CWS (not crx4chrome and similar... ), because my experience so far of using various 360EE variants in my Vista laptop has proved that any of my already installed extensions a. may suddenly disappear completely from CWS, for various reasons... b. be updated to a version not working correctly/at all with a specific 360EE version; this is often true for 360EEv11 (Chromium 69 based) and 360EEv12 (Chromium 78 based), but I expect to hit similar issues in the near future even for 360EEv13 (Chromium 86 based), because most Chrome extensions are developed/updated to target current Chrome (v92?) and declared backwards compatibility in CWS is often just a joke... It's too late if I first update an extension but then discover it's broken, because CWS, unlike AMO, doesn't host previous version(s) of an extension... Below is an excerpt of a previous edit (saved in an e-mail notification) of https://msfn.org/board/topic/182993-360-extreme-explorer-arcticfoxie-versions/?tab=comments#comment-1205088 I've been mostly using the Russian RePacks of 360EE variants and while I was always able to add Chrome extensions directly from CWS, never have I observed one automatically update... One can perform a simple test to verify: Browse crx4chrome or similar third party Chrome extension archives, search there for and download the .CRX file of a previous version of an extension extant in CWS (all crx4chrome hosted files were originally retrieved from CWS) ; manually install by dropping the file on the Extensions tab (chrome://extensions/) ... No matter how long you give it (hours, days, etc,), the extension won't be auto-updated to the latest version found inside CWS; often times, this is a blessing in disguise, because, despite CWS saying the opposite, the updated version won't "like" your version of 360EE (being sourced from an older Chromium codebase...). However, in the event you do want to update an installed extension, again this is not straightforward ; visiting the CWS entry for the extension, you're only given a choice to "Remove from Chrome", not "Update Extension"; to "update", you have to actually first "remove", but this means losing all extension custom settings/modifications... Several Chrome extensions offer the choice of backing-up settings/configuration prior to removal (with the option of importing back in a fresh installation), which makes updating them in 360EE somewhat less cumbersome...

... I'm not following closely the developments in this thread (am notified via e-mails, though ), but are you people here aware of https://github.com/NeverDecaf/chromium-web-store ? It is supposed to re-enable CWS functionality in Ungoogled-Chromium, perhaps it can also be used in your "ungoogled" 360EE flavours?