VistaLover

... Not being a JS coder and not involved at all in IT during the time of the "big browser wars", I was unaware of such coding subtleties - was it Microsoft (and their IE) then the "true first" ? FWIW, I tried the sample download page in my IE9 copy and it didn't work there ; nor did it work in FxESR 52 (which is understandable now, given the linked "Browser compatibility" table above) ... As for UXP, MC first declared an interest in implementing this feature in Pale Moon some 5 1/2 years ago, but good ol' M.A.T. was adamant against it ; with the latter "out of the picture", it was not until April of last year that it finally got implemented but, due to MC "being on the fence about it", only behind a disabled about:config pref ; it's all inside: https://repo.palemoon.org/MoonchildProductions/UXP/issues/595

... And this is a 100% pure Googl-ism , as the Browser compatibility table there indicates that feature as present in Google Chrome 1.0 (!), released 2008-12-11, but only implemented in Mozilla Firefox starting with v66.0, released more than 11 years (!) later ...

... Confirmed in my copy of Serpent 52 ; to make the JS code served by that site perform its intended task (i.e. produce a file to download), load "about:config", locate pref "dom.window.event.enabled" and toggle its value to "true" - then the download should work; unsure whether toggling that pref has unforeseen security implications ... Greetings

... You're welcome ... ... Just so you know, the UXP platform (i.e. St52/NM28 browsers) now supports natively the javascript "??=" operator), so the "Modify HTTP Response"-based solution isn't the most current; the solutions I linked to above (requiring either uBO or Greasemonkey) are quasi-global ones, that encompass almost 99% of the discourse-based forums found on-line ; whereas the option you chose requires adding additional domains for the forums you'll find being "unsupported" in your future browsing; just my 2c ... Best wishes.

... Please, refer to the roytam1 forks as Serpent 52 and New Moon 28 , so as not to unnecessarily vex "upstream" (Basilisk-dev, MCP) and also NOT create confusion among mis-informed fork users, that may end up seeking support "there" for their browser(s) running on XP/Vista ; thanks in advance... As for the issue you reported, it has been already reported inside these threads more times than I'd care to remember ; use the Forums Search utility, search for "discourse based forums" ; two, fairly recent, posts from yours truly : 1 , 2 Best regards ... PS: @reboot12 : You may want to fix the links in your report above, as both link to: https://msfn.org/board/topic/185966-my-browser-builds-part-5/page/12/

... Well, as explained by Moonchild in the linked PMForums comment, the "underlying issue" involves "ghost browser windows" that keep devouring H/W resources even after tabs have been closed; are these ghost windows being killed just by reloading a tab via that extension? Unless the ghost window(s) are being created ONLY after a tab has been closed ... As also noted by MC, e10s is the way "mainstream" browser engines mitigate the underlying issue, but the upstream apps are single-process ONLY; of the roytam1 forks, St52/55 can be forced to enable e10s, but this is an unsupported configuration (which, in itself, requires "better" H/W ) that uses a half-baked multiprocess implementation (never meant to work under XP, BTW) by Mozilla from the Fx52 era, inadequate at best to handle bloated web pages (read: apps) in 2024... As for GitHub, I wouldn't want a GH tab auto-reload in the middle of me composing a New Issue or comment ... Thank you , though, for the recommendation (which, again, is no good for "upstream" and NM28, since WEs are out of the question...).

... Yeah, as a heavy GitHub user in St52, I often get the symptoms the OP there reported ; MS have recently turned GH into an even more "massive beast" , now serving huge ReactJS code that has to be rendered client-side, causing exacerbated sluggishness and more frequent need to just restart the browser - things do get worse when media-rich content (bloated social media portals like FB/IG/X/YT/etc.) are being visited alongside GH ; I mean, how often during one's workflow does one have to restart it? If it's less than every two hours or so, the browser becomes unfit for its purpose ... ... Despite what MCP may think, the "web at large" won't change towards a direction "they" would've hoped... The dominant web engine(s) has supported e10s for many years now, as a consequence ALL the web frameworks used blindly by web authors to build pages (or, rather, webAPPs) have that support as a prerequisite; despite ALL the talk about increased security inherent in a single-process browser (their main argument for staying SP), which I won't argue with by the way, such concerns are non-existent to web designers, who quickly put up something that would work fast/as expected with recent Chromium/Firefox implementations on mobile (their first priority now, I'd say ) and with Win10/11 on desktop... ... I wouldn't bet any serious money on that likelihood - because of UXP's many current shortcomings on GitHub, since the start of the year I find myself more on Chromium 86/87 forks for that (and will likely move on to the recently surfaced, Vista-x86-compatible, "higher Chromium" varieties (115/119/121) whenever GH breaks considerably on 86/87) ...

... Well, this "patch" isn't coming from me , like I said: Thanks for your efforts , despite...

... When upstream (Moonchild Productions) forked UXP from a Mozilla ESR 52.6.0 code snapshot (which had FULL support for ALL Vista SP2 features, including Aero Glass in its default theme ), the first task they undertook was to completely excise ALL code features pertaining to Windows XP and Vista support from their future application platform, as they targeted ONLY Win7+; this hunt for XP/Vista code was a relentless one, spearheaded by then lead dev Matt A. Tobin, a sworn enemy of these OSes ... When current maintainer (roytam1) of these UXP forks attempted to restore the removed support by upstream, his main focus was on the Windows XP OS, as it's the one he's using too and the one the overwhelming majority of his targeted "audience" uses... It would appear that while most of the XP stuff got re-introduced into the tree successfully, the same wasn't true for Vista , at least where St52's visual aspects (on that OS) are concerned; St52 sports the Australis GUI, OTOH NM28 inherits visual code from a pre-Australis era, and I can confirm that Aero Glass works as intended in NM28 under Vista... A similar issue exists for Serpent 55 under Vista ; initial ports of the ill-fated upstream application Basilisk55/moebius would be fully compatible with Vista's Aero, but at later stage (when St55 became a roytam1 "exclusive"), porting code from forked-UXP and other, XP-exclusive, third party repos BROKE Aero (and Widevine CDM, for that matter) on St55/Vista ... It's worth noting that Aero Glass works fine for both St52/55 on Win7, so it's only the Vista side of it that's currently broken on these browsers... I, and several other, Vista users had reported at the time (and, on occasion, at later instances ) the visual shortcomings of St52/55 under Vista, but, as time went by, these remained without being addressed ; I grew to live with them ; after all, what can one do when one isn't a Mozilla browser coder ? These threads were living previously on an XP-specific MSFN subforum, mentioning Vista there always made me feel like walking on thin ice ... TL:DR: Roy Tam doesn't have a Vista OS (VM?) to debug this; given Vista's low popularity/user base, especially among the forked-UXP apps crowd, this "issue" (non-existent under XP, which doesn't support Aero, ofc) has silently become a WONTFIX for us, Vista luddites ... FWIW, I'm using a self-patched version of the "upstream" Photonic complete theme on Serpent 52 (the theme ONLY supports official Basilisk/PM on Win7+), that gives me a good approximation of Aero under Vista: Greetings ...

... Can't confirm here with previous NM28 generic 32-bit build: The sample clip I used was: https://vk.com/video-2611_456242587 ... and, as already advised: 1. Provide actual test links/URLs 2. If the problem clip is log-in ONLY, mere mortals without a VK account can't troubleshoot it... 3. When reporting issues in an English speaking forum, change your browser's language pack to en-US prior to posting debug details (logs, errors, images, etc,) 4. Whenever possible, try to include Web/Browser/Error Console messages in (English) text format, NOT images...

... Wow ; he's totally clueless, indeed ; the "shortcuts pane" wasn't implemented by @AstroSkipper per se; it was already implemented by GH dev hawkeye116477 (and merged by JustOff) in: https://github.com/gorhill/uBlock-for-firefox-legacy/commit/1e0b42e155373c5d37244e3ee079d357fbb9be48 This merged change happens to be already present inside the 1.16.4.31b2 build (by hawkeye116477), the starting point for Astro's later "releases" ...

... Apologies for bringing this up, but was any further (security) update released for Chrome v109 on WS 2008 R2 after last October's release, v109.0.5414.168 ? Thanks in advance for any info ...

... And where one would put the chairs? All in jest, as you said , it's quite obvious you intended to type "tabs" there... Take good care ...

... On Windows < 8, Supermium (Sm) has issues correctly rendering woffs (remote/web fonts) on web pages (in addition to emojis, which, unlike in Mozilla apps, seems to be a Chromium-specific issue ); you may need to install additional fonts in your Vista machine and/or use an extension for emojis; or you could try enforcing the GDI font rendering flag; some relevant GH issues: https://github.com/win32ss/supermium/issues/227 https://github.com/win32ss/supermium/issues/143 https://github.com/win32ss/supermium/issues/138 https://github.com/win32ss/supermium/issues/134 https://github.com/win32ss/supermium/issues/69 https://github.com/win32ss/supermium/issues/33

... But these two are supposed to really make a difference (i.e. considerably reduce RAM usage on XP) ONLY where the VC++2015-2019 redistributable (the last XP-compatible one was v14.28.29213.0) is already installed : https://github.com/win32ss/supermium/issues/235#issuecomment-1925433278

... For people on WinXP SP3 "trialing" the latest Sm-121-hf x86 release, win32 is kindly providing recompiled+rebased versions of files: that will reduce excessive RAM usage by the browser on pre-Vista OSes: https://github.com/win32ss/supermium/issues/204#issuecomment-1924048080 https://github.com/win32ss/supermium/issues/204#issuecomment-1924437338 https://github.com/win32ss/supermium/issues/204#issuecomment-1924647139

... As I and several others already wrote, that WidevineCDM dll requires Win7SP1+ functions to run; even on Win7SP1+, the CDM won't properly work on many "popular" DRM'ed services (Netflix, Spotify, hulu, etc.), because those sites demand its VMP (Verified Media Path) feature, but open-source (non-mainstream) implementations like Supermium aren't being sanctioned by Google for that purpose... https://github.com/win32ss/supermium/issues/169#issuecomment-1901651703 https://github.com/win32ss/supermium/issues/127 https://github.com/win32ss/supermium/issues/61

https://github.com/win32ss/supermium/issues/199

... For future references : https://wiki.mozilla.org/Firefox/CommandLineOptions and... https://wiki.mozilla.org/Firefox/CommandLineOptions#-purgecaches

... Yes, I was quite vexed myself when I read those "speculations" by "you-know-whom" MCP dev, interspersed with additional insults against "this" community here; that dev seems to know very little about "our" apps other than the fact they work on XP/Vista, too; this "our version of UXP vs theirs" argument sounds like a broken record by now; the differences are well defined and known by most members here, but, apparently, not by upstream; NM28, a fork of official PM, doesn't support WEs, so how could it have been that Astro's version implements WebEx features "they" don't implement? Once more, "they" are very quick to cast a stone upon "us" and actually did what they, in the recent past, accused us of doing: blaming the other party "out of habit" ... In his last paragraph, that dev tries to "soften" his criticism, I'll give him that, but then "father" MC himself intervenes to restore the "status quo"; how hypocritical (on all of them) to speak about "that level of hostility towards our (their) projects", when it's the years-long "treatment" they've been giving us to this day ... (Going to make myself a cup of hot chocolate now, with extra sugar added, to alleviate all that, unfortunate, bitterness disseminating from that "other forum" ) AstroSkipper: This whole situation surrounding your uBO efforts brings to mind the English saying: "No good deed goes unpunished", wouldn't you agree? Kindest regards

The off-line variety should've been downloaded ... https://cdn.epicbrowser.com/v120/mini_installer.exe And, this is just an educated guess , Epic-120 should require at least Win10 ... EDIT: There has been info by another member that, in fact, it does launch under Win7 ...

... FWIW, this very same bug can be observed in the latest St55 (32-bit, buildID=20240125063308) ; I suspect the "fix" is similar, at least according to: https://github.com/roytam1/basilisk55/commit/323bda6dcc13f3875ef36bbce15b59107ac0f09e BTW, I haven't updated my daily driver, St52, but I expect the bug to be there, too, since it affects ALL UXP-based apps ...

... OT : This simple MUC search doesn't tell the whole story : https://support.microsoft.com/en-us/topic/windows-installer-4-5-is-available-bf06be18-3e0a-d5eb-4549-b482f67e1c46 https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/Msi/windows-installer-redistributables.md (TL;DR: KB942288 is Windows_Installer-v4.5; redistributables existed for XP SP2/3 through to Vista SP0/1 - and their Server counterparts ; existed, because now evil MS have removed them from the Download Center )

... Er, you might want to correct that LINK of yours there (I'm reading this "heated" thread today, on a Sunday, so just stumbled on that) ...

... You do have DRM-enabled web browsers under Win7+, but NOT for that long ... Google own the Widevine CDM (blackboxed, closed-source module that deals with DRM decryption) and while themselves have stopped supporting Win7/8/8.1 in their main browser (Chrome), they have prolonged Win7 support in the CDM because their sidekicks, Mozilla, still support those OSes in their Fx115esr branch (until autumn this year?) and, guess what, that branch still ships with a version of Widevine CDM (licenced by Google) that should work on those OSes - after Mozilla drops Win7/8/8.1 support, all bets are off... Win7 will inevitably become like Vista SP2, where the CDM doesn't work at all in any supported browser, so all those "compatible ones" will cease working then ...