VistaLover

As most following these threads probably know already , all the XP/Vista compatible 360EE variants (v11/12/13/13.5) are NOT compatible with MV3 Chrome extensions (which require at least Chromium 88) and, in the same vein, are NOT compatible with the "new" Chrome Web Store (CWS) ... Since sometime on Feb 13th, 2024 (depending on your location), "old CWS" URIs for extensions/themes/etc., of the format: https://chrome.google.com/webstore/detail/* now auto-redirect to the "new CWS" URIs for the same extensions/themes/etc., of the format: https://chromewebstore.google.com/detail/* This isn't a first occurrence, the same thing used to take place during the autumn of 2023, when the eventual migration to the new CWS was announced beforehand: https://support.google.com/chrome/thread/231812199 https://blog.google/products/chrome/google-chrome-web-store-redesign/ https://9to5google.com/2023/11/20/google-chrome-web-store-redesign-preview/ In late December 2023, this auto-redirection (old -> new CWS) in non-supported Chrome versions stopped taking place, but in the loaded old CWS appeared a top info-banner indicating that: The user could disregard/remove this banner and continue as usual ... Well, Jan 31st 2024 came and went, but the "status quo" remained in place until Feb 13th, when the auto-redirection to the new CWS resumed ... Google staff seem to have a perverse sense of "humour" , because after the auto-redirection has been completed, in non-supported Chrome versions, a new in-page banner is being displayed, stating: However, clicking on the "Visit legacy store" area (JS-controlled button) will only start a vicious circle , resulting in that same "new CWS" page ... Issues with the "new CWS": The older the 360EE version you have, the more page rendering issues you'll get ; below, a screengrab with 360EEv11 (Ch69-based): Apart from the overlapping fonts, all "carousels" in the page are absent/non-functioning, because they require JS+CSS code not supported there ; these rendering issues are less/absent on higher versions of 360EE (v12+) ... But the main issue is that you can't install/download extensions from the "new CWS", because the "Add to Chrome" button is greyed out ... Mitigations This third party userscript, when installed (requires a userscript manager, e.g. Violentmonkey, Tampermonkey, etc.), will make the "Add to Chrome" button active again, however its functionality will now be limited, in that it will only enable a .crx file download to disk, not proper installation (as was the case with the "old CWS"); after saving to disk, the user has to drag-n-drop the saved file onto the "chrome://extensions/" internal tab, for the installation to proceed... The problem with that userscript is that the "name" of the downloaded extension always comes up as "undefined" (the "version" comes up correctly), so some renaming is in order after the download (perhaps one savvy person here could fix the script in that regard? ) ... Another solution I've been using is based on this extension ; the problem is that the latest version, 1.51, compatible with the "new CWS", is of the MV3-type, thus incompatible with 360EE (and Kafan MiniBrowser); here's an MV2 custom patch that will install and function as expected under Ch<88: https://www.mediafire.com/file/on5h2vit08a1xk6/1.51-mgdjkephahlgejakcnbooghhocmoppai-MV2.crx/file BTW, this is an "anonymous" upload that will expire after 2 wks of inactivity ; once installed, use the context menu on a "new CWS" tab to fetch a .CRX file to disk... Caveats of the two solutions above is that the "new CWS" won't label incompatibilities with Ch<88, so the .CRX you end up saving to disk may well be an MV3-type extension, incompatible with your "legacy" Chrome browser ; I probe the CRX files with 7-zip, opening their manifest.json files with an editor and checking for the "manifest_version" value (to be 2, that is...). A third option that might die any day now is the following: Make a bookmark of below URI: https://chrome.google.com/webstore/old/ Once loaded, it'll auto-redirect to: https://chrome.google.com/webstore/category/extensions which is STILL the "old CWS"; as long as your browsing remains confined inside that very one tab, you can access extension-URIs in the old format, e.g. by clicking on suggestions or searching in the old-store's searchbar (and make sure the search result is opened in the same tab): The back and forward nav buttons are allowed, but be sure not to click the reload one (will get you to the new CWS) ; since this is the "old CWS", it won't offer (to your "legacy" browser) MV3-type extensions in the suggestions/search results ... Of course, as time moves on, the MV2-type extensions now found inside the "new CWS" will be eventually all migrated to MV3 or purged completely, thus these workarounds will become moot... Save your MV2-type indispensable Chrome extensions while you can... PS: I'm dead certain evil Google will make sure your Ch<88 will become less effective in browsing the web over time, but I feel it'll still be good for the next two years, at least - here's hoping (of course, browsers based on much newer Chrome versions have recently surfaced that can launch under XP/Vista, granted with several issues so far, but this analysis was targeting mainly 360EE/KMB users) ...

... I was mainly unavailable at the time that request was made; RL issues , plus I was researching/studying something else then, that couldn't be interrupted; hope you understand ... As a matter of fact, I didn't come up myself with anything else adding more "substance" to what you have already mentioned about the startupCache ; it would seem the relevant literature about it has been wiped out by now... Mozilla mention very little about it now, even below URI: https://firefox-source-docs.mozilla.org/contributing/directory_structure.html#startupcache has an empty description for it (which, personally, I find totally unacceptable ); mozillazine (not directly affiliated with Mozilla) do mention something (but very little, TBH) not in relation to Fx, but in relation to the e-mail client, Thunderbird: https://kb.mozillazine.org/Profile_folder_-_Thunderbird More info about the referenced startupCache.4.little file (inside the startupCache directory) was to be found in MSFN itself: https://msfn.org/board/topic/180462-my-browser-builds-part-2/?do=findComment&comment=1196115 The info there seems to be echoed by this dev's comment: https://groups.google.com/g/mozilla.dev.extensions/c/HM2GNAll_aU Unless instructed otherwise, for troubleshooting purposes (like in the recent case ), I tend to leave it alone in my UXP-based browsers; once a month I perform some profile "housekeeping" and IF the ".little" file has grown somewhat bigger , I may manually delete it - I've also confirmed it is, indeed, a compressed file format, because it can be easily extracted with 7-zip and its contents then probed ... That's all I found out, basically ... Regards.

... I see now (but missed it altogether initially, here being a "legacy" browser thread ) ; the first (small) "derailment" then was by my dear friend Nicolaas :

... He's mentioned that publicly in a previous post, the gist of it being: "it's difficult to familiarise with and old, as it hasn't been updated since 2021" (speaking about the XUL variant, of course) ...

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