VistaLover

... If you search my posts' history with "Serpent 55" as a search filter, no doubt you'll find I posted about this repeatedly... "55" as an appVersion was chosen by upstream for their ill-fated Moebius platform purely for "sensational-istic" purposes... The platform code itself was forked off a code snapshot of an early version of Mozilla Nightly 53.0a1, so not even close to release channel Firefox v53.0.x ...

It is/was the API+GUI of Mozilla Firefox's Download Manager that existed up to version 25.0.1 in the release channel (and v24.8.1 in the ESR channel); and even there, it was not the default setting, but had to be enabled via an about:config pref: browser.download.useToolkitUI;true Here is a screengrab from FxESR 24.8.1: FWIW, NASA Launch third party complete theme, on Vista SP2 32-bit, with aero turned on... TDM had its own "download history", stored in file downloads.sqlite inside the browser's profile, and was decoupled from the browser's "browsing history"... The underlying code that enabled TDM in Fx 24/25 (the default in earlier Fx versions) was finally removed in Fx 26+, in favour of an async, JS-based, Download Manager API, that integrates DM with the "Library" API; as a result, "download history" became part of "browsing history", stored in file places.sqlite inside the profile... In the screengrab below, the GUI of JS-DM (most are familiar with...) in FxESR 24.8.1, with the default setting browser.download.useToolkitUI;false How is that relevant to UXP now, I hear you ask? Well, our "beloved" Matt A. Tobin is bringing the old TDM back, at least where his Binary Outcast UXP applications (Borealis Navigator+Interlink Mail & News) are concerned: https://forum.palemoon.org/viewtopic.php?p=217500#p217500 https://forum.palemoon.org/viewtopic.php?p=217567#p217567 For those harbouring a liking to TDM's GUI (over the new one), one of my most favourite "legacy" extensions, Downloads Window, does its best to simulate that GUI (while the underlying engine/API remains unchanged): https://addons.basilisk-browser.org/addon/downloads-window/ https://addons.palemoon.org/addon/downloads-window/ caa:addon/downloads-window/versions (v0.6.8 is to be found here) It's a pity the original "bitbucket" source repository by author ungram has been now withdrawn...

Hi @roytam1 , I do hope you're well I just noticed the following commit, that found its way into the custom branch of your UXP fork: Issue #1793 - Only use Glass on the Toolkit Download Manager on Windows 7 margin-top: 3px; } -@media (-moz-windows-compositor) { +@media (-moz-windows-compositor) and (-moz-os-version: windows-win7) { #downloadManager { -moz-appearance: -moz-win-glass; background: transparent; I understand this was merged as-is from upstream (mattatobin), they only support Win7+; but Glass (aka Aero) is also extant in Windows Vista, will that specific commit "break" the UI of toolkit download manager under Vista? If yes, could you include Vista there (e.g. (-moz-os-version: windows-vista) ) ? ... Thanks for your unwavering efforts thus far

FWIW, today @RainyShadow's site does load fully/as expected even from my default Greek IP : This is from latest St52, 32-bit; by the looks of it, they ("avb.bg") must have suffered a temporary glitch with their CDNs, serving different parts of the world... Hopefully, the issue has been also rectified for RainyShadow, so probably crisis averted (for now?) ...

@RainyShadow : This all appears to be IP related ... I am posting now from my 360EEv11 profile (fork of Chromium 69), on my Vista SP2 x86 laptop, and when loading https://www.abv.bg from my (default) Greek IP, or from a UK IP (via a "VPN" extension), I get exactly what you get: But when accessing your URL from a US (or Dutch) IP (via the Browsec "VPN" extension), I get the expected result: So I guess that is why @XPerceniol can load OK that homepage, being in the US himself... The plot thickens...

... Freedom of expression? My... behind! (pardon my French ... Pun intended, as OPer is from France ). Loading the linked URI in latest Serpent 52.9.0 32-bit, I'm seeing the following: ShadowRoot is part of Google Chrome's WebComponents framework... Shaka Player is a Google-owned web player framework, in the posted screengrab it's looking for EME (Encrypted Media Extensions), i.e. DRM support (aka WidevineCDM, another Google "asset" ) in the browser... Finally, apart from the CORS issue spotted by @roytam1 , the site produces two more errors: To sum up, this is yet another site coded in a way to cater exclusively to latest Chrome and variants ; I wouldn't call this "freedom", would you? (at least where user freedom to choose a browser is concerned... ); in the same vein, citing that 360EE and (Chr)Edge can handle the site/web player fine is a redundant thing to say; the web of 2021 revolves solely around Chrome, period...

... All this has already been explained in fine detail last March 30th: TL;DR If you first download to disk an XPI file of the extension (github-wc-polyfill), in order to install in Serpent 52.9.0 you have to first patch its install.rdf file; if you, OTOH, manually install the latest release (currently it's v1.2.0) direct from GitHub, or you already have an older version installed, no patching is required to update to the latest release; the GitHub update.xml file is responsible for this behaviour...

... An English speaking user of 360EE v13 has apparently posted in their official forums, 3 days ago, alerting them about that specific misspelling, along with other shortcomings of the "Speedup" utility: https://bbs.360.cn/thread-15985856-1-1.html ... Any chance you are user "652961752", dear friend? (just joking, of course...) They seem to want to fix things, that's good to know ... After reading some past comments in their official forum, I got the distinct idea it was generally frowned upon to post in English there, so at least that notion must have changed since then...

That URI only links to deprecated v11 (final build 2251); they haven't made an English page for later versions... https://browser.360.cn/ee/ (only in Chinese) currently links to v13 (final build 2250) - previously, it used to hold links to v12 ... On the header of that page, v13.5 (beta build 1030) is also linked...

As hinted, to even attempt an installation on Vista SP2 64-bit, you'd need to modify the x64 MSI installer of JRE 16.0.1 with Orca, in order to lower the LaunchCondition from 601 to 600; see pic below: After installation, you'd need the Extended Kernel, for JRE 16 to run successfully (hopefully ) on that Vista SP2 x64 machine...

I can confirm... I downloaded OpenJDK16U-jre_x86-32_windows_hotspot_16.0.1_9.zip extracted it and probed .exe and .dll files inside the bin dir with DependencyWalker (DW); many DLLs look for K32* functions inside kernel32.dll (where they normally are in Win7+), but in Vista SP2 these function reside, IINM, inside psapi.dll ...

Well, I tried to run OpenJDK16U-jre_x86-32_windows_hotspot_16.0.1_9.msi on my Vista SP2 x86 laptop, this is what I was met with: Probably something that can be mitigated via Orca. but not gonna try it now... Also, https://adoptopenjdk.net/installation.html?variant=openjdk16&jvmVariant=hotspot#x86-32_win-jre suggests: i.e. the MSI installer will install the 32-bit variant of JRE 16 only on a Win7+ 64-bit host ; so, even when using Orca, I probably won't be able to install on my Vista x86 OS ... In any case, if @winvispixp is to try AdoptOpenJDK on his Vista SP2 64-bit machine, some tinkering of the installer might be needed...

Thanks for that ; also nice to see that 32-bit support hasn't been abandoned by them ! However, https://adoptopenjdk.net/releases.html?variant=openjdk16&jvmVariant=hotspot suggests only Windows2012r2 or later is supported (?) ...

JDK 16 bundles JRE 16; Java compiled apps will just use the JRE, as pointed out by @SigmaTel71 ... AFAIK, Oracle no longer supply standalone JRE installers past JRE 8 (8u291 is the latest official release); as you might already know, 32-bit support was also dropped past 8 ...

It appears the official 360 forum thread pertaining to this new 13.5 beta development cycle is located in the URI below (all in Chinese): https://bbs.360.cn/thread-15980045-1-1.html latest beta build already at 13.5.1030.0... Release Notes history posted towards the end of the initial post; below a screenshot, inline-translated into English:

GitLab have started implementing the Google-devised Web Components JS framework, en route to their annual, major, software upgrade... So, "monkey see, monkey do" , i.e. following close in the footsteps of major competitor, GitHub... Application platforms with non-existent or half-baked WC support (UXP in "our" case) will fail to load GitLab pages correctly, hence https://github.com/JustOff/github-wc-polyfill/issues/25 was filed... If you care to read, JustOff initially declined to indulge us (I suppose his ousting from the core of the UXP devs doesn't help in such cases ), but further input from users affected (me included) has, fortunately, caused him to rethink things... FWIW, this is the original issue opened in the GitLab tracker: https://gitlab.com/gitlab-org/gitlab/-/issues/333598 As you'd imagine, this is still OPEN, with no official response from any GL representative; probably another "WON'TFIX"...

... Well, indeed, "the proof is in the pudding" : But please, let's not turn this thread into "which VPN/Proxy service works best for you?" debate...

@IXOYE I can confirm, with latest Serpent 52.9.0 on Vista SP2 32-bit ... My EU IP results in a blank page when attempting to load https://mevius.5ch.net/ Serpent 52 will also produce a 451 HTTP error, but you have to open the Web Console to see it: However, I'm not convinced this block is implemented necessarily on "our" European side, nor that it has to do with being inside a "Western" democracy (BTW, did you vote in the recent French elections? When citizens abstain en mass from elections (as I've heard was the case...), so called "democracies" rot into oligarchies - OT, of course, here, so apologies for bringing this up ) ... On further testing, Asian and US (yes, US of A) IPs do load that hostname, so perhaps an ACL (access-control-list) is imposed on "their" side? OTOH, why would the Japanese block EU IPs? Not a new thing, sadly... The net hasn't been a liberal place since at least ten years ago, if not more... "Political correctness" and rights restrictions (for media content) imposed by the big powers that be have placed strict geo-blocks on what one can access freely from one's physical location... And I'm not even discussing authoritarian regimes that censor net access as a whole; I'm simply talking here about net censorship in "democratic" regimes/states... That is why VPNs are considered a must in this day and age... 28/06/2021 EDIT: It does indeed appear that the EU IP block is done on the Japanese side, as a result of them not willing to conform to the GDPR EU laws; relevant reference from the wikipedia entry for 451 HTTP Error:

A big thank you to all parties involved... However, seeing MSFN down for more than 5 days (the longest since the time I registered), without any clues as to what was going on, "member flags" was the least of my worries...

Thanks for the prompt explanation ; so, a change made 11 months ago, that only now fell on my radar... I'm definitely getting old... And thanks for, at least, "fixing" UA-related strings (to appear, hopefully, in coming weekend's releases) ...

FWIW, I never let any browser extension autoupdate here ; I periodically test manually for updated extensions and when one or more are found, I first read the relevant Release Notes (when available), then make a note of the currently installed version(s), finally make back-ups of these "previous" extension versions, in case something goes SNAFU (after the extension(s) has been manually updated) and a need presents itself to revert to the ol' good, working versions... This is a habit I picked up since my late-ish Firefox "days", when several "legacy" extensions of mine (e.g Stylish, Greasemonkey) would autoupdate to the much-crippled WebExtension iteration of theirs; the habit became a must when my favourite "legacy" extensions/Complete Themes vanished from AMO... Both in FirefoxESR 52.9.1 and Serpent 52.9.0 (the latter now pointed to AMO to look for updated extensions), it isn't uncommon I am being offered an update to an existing WE addon, only to find out, to my distress , that the update doesn't function properly/at all with a Mozilla 52 based platform... This is often because Mozilla have the ill tendency to blanket-label all WEs as being "Firefox 48 and higher" compatible, by virtue of them simply being "Web Extensions"; i.e., they don't bother to test on older browser versions (as they don't expect anyone to be on anything other than the latest "Release" and "ESR" Fx versions ) ... TL;DR: No auto-update is allowed to take place here (this stance not limited to browser extensions only, but am afraid that is definitely OT ) ...

@roytam1 : Something to keep an eye on (and probably revert/omit to maintain XP compatibility) : #1782 Remove support for obsolete system themes from Goanna Issue #1782: Remove Luna, Royale and Zune support from the platform It never ceases to amaze me though that, despite the fact official UXP has currently a plethora of open issues regarding its deficits in tackling the modern web , the dev team are obsessed with opening "new issues" targeting revengefully Windows XP... I guess destroying is much more easier than creating,,, This might have changed in some prior release, it just so happens I took notice of it in the latest one... ALL references to the native platform name, Goanna, have been replaced with Gecko, Firefox's one, in ALL three variants of the browser User Agent string: Additionally, previous about:config entries goanna.buildID & goanna.mstone (Goanna milestone) have been replaced with gecko.buildID & gecko.mstone, respectively... Was the above intentional on your part? Is New Moon 27 being "Firefox-ified" ? FTR, I use the Fx-compat setting, two "Gecko" fragments with two different values looks confusing...

Well, digital "Gods" sure work in mysterious ways ; at least you're now back and running! One last thing that hasn't been answered and am really curious about: If you use IE8 now without ProxHTTPSProxy, does the plain HTTP logo URI, http://helpforum.sky.com/html/assets/sky-community-v6.png load? Because you had said that previously it didn't load at all, with or without ProxHTTPSProxy... How are things now?

The Proton GUI introduced in Fx 89.0 release channel can, for now, be DISABLED via toggling ALL "proton"-enabled about:config prefs, followed by a browser restart - those prefs will eventually be removed in future Fx versions, but user.js+userChrome.css+userContent.css based solutions are already available; until Mozilla kills them, too... Disabling Proton will revert the GUI to Photon, first introduced with Fx Quantum 57.0...

@Dave-H : Thanks to @Sampei.Nihira and @XPerceniol, it has been established by this community that indeed something is broken in your XP partition ... I had a read of https://www.michev.info/Blog/Post/1435/windows-certificate-stores Perhaps a full system restore (instead of only a registry restore) would have been better... Do you currently have System Restore Points prior to the suspect Certs Update? Have you tried re-applying the Certs Update, followed by a system reboot? Are there any expired Intermediate Server Certificates present inside your Cert Store?