VistaLover

FWIW, there's nothing "standard" about NM27 here ; to add to what Mathwiz has posted: "Pale Moon" is an upstream browser application, which has a GUI from the pre-Australis Fx era; also, members here must understand the distinction between platform and application (Mozilla are the ones to blame for this confusion, because they had equated the Mozilla platform, not used solely by Fx, to their main browser, Firefox) ... When PM was at its major version 27 (did not support XP, Vista support was rudimentary), the platform it was built on was called Tycho, a fork of the Mozilla ESR 38 platform - the browser engine of PM27 was called Goanna version 3. The roytam1 fork derived from PM27 was/is New Moon 27 (NM27) ; as the web became more-and-more Googl-ised , PM27/Tycho started being crippled at loading many popular sites, so "upstream" (MCP) abandoned the Tycho platform and moved on, first to UXP Take 1 (aka Moebius), forked from a Mozilla 53.0a1 platform snapshot, and soon after to UXP Take 2 (just UXP now), forked from Mozilla ESR 52[.6] platform; PM27 became PM28; Pale Moon is currently at v33.0, but it's still built on UXP; both the paltform (UXP) and the browser application (PM) are being developed independently from Mozilla/Firefox... When upstream (MCP) abandoned Tycho (and PM27), roytam1 chose to keep his forked platform and browser (NM27) for the sake of Win2k/XP users on very old H/W, that doesn't support the SSE2+ instruction set ; as of this writing, NM27 and its browser engine, Goanna 3, is being "updated" based on a new "upstream", the developer (rmottola) behind the Artic-Fox project; this project aims to develop a (semi-)usable browser on old Macs, unsupported by Apple and the mainstream browser vendors; the project strives to "uplift" the browser from a Mozilla 38 platform snapshot (like in PM27/Tycho) to more recent versions, hence the large number of weekly updates (there's a lot of catching-up to do when you're still at a Fx mid-40s level) ... Also, Arctic-Fox isn't New Moon 27, hence several bugs that plague the latter are being reported by (the few?) NM27 users... To put it bluntly, I have now no need for this fork, because its web-compatibility is severely impaired in 2024; in addition to that, Roy is publishing SSE-compatible builds of NM28+St52, so if your old H/W can cope, it's advisable you use these instead of NM27... NM27 has inherited from PM27 a "status-4-ever" internal component, but as the platform is being updated by rmottola to Fx43+, this component has been partially BROKEN, breaking with it several download-related functions/extensions/userstyles/userscripts etc.; I have kept, for archival purposes, a NM27 build from 20220812, which seems to be the last with no such issues... As for NM28 (and St52), this is being updated mostly by backporting MCP code, especially in the platform aspect of it, and occasionally PM-specific (and Bk-specific) code is also being backported; and don't let the appVersion (28) confuse you ; Roy, for reasons he has explained in the past, decided to "freeze" the major version at 28, but latest NM28 embeds platform code to be found even in the latest PM33 "official" release ...

... So, you used the Fx-120 based one; try to use as value of "general.useragent.override.elektroda.pl" just "Chrome" (without the " ") and report back ...

... Which SSUAO value did you in fact use there? Was it the Fx-120 one or the "just Chrome" one ? In any case, being able to use that bloated (if I may say so ) portal for several hours is still better than not being able to even access it at all ... I don't have an account there, so it's just impossible for me to further troubleshoot ... It's possible they're (still) doing some form of fingerprinting once every several hours and then you're kicked out ... If I had to bet some money , I'd say evil CloudFlare is behind all of this... Kind regards.

... Nope, Mathwiz is correct; at the time MCP cut UXP (Take 2, to be precise) from the Mozilla ESR 52 platform, the platform was at its 52.6 release point... https://repo.palemoon.org/MoonchildProductions/UXP https://repo.palemoon.org/MoonchildProductions/UXP/commits/branch/master?page=147

... You're NOT doing it wrong , rather different; reboot12 compared the same 32-bit vs 64-bit apps, but said 32-bit app variants reside inside the 32-bit subsystem (SysWOW64) extant in his 64-bit OS; can't tell who's right or wrong that way, as the results are certain to differ, aren't they? ... ... Darn! I wasn't paying attention ... The KBs in reboot12's post were pertaining to RAM usage, not to .EXE file sizes, which is what, apparently, is being compared in 66cats's screengrab; in any case, I expect the "behaviour" of (32-bit) EXEs inside SysWOW64 (unique to x64 OS) to be different to the "behaviour" of the (32-bit) same EXEs inside System32 of a x86 OS...

... Please, read this ... Best regards !

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