VistaLover

... The v126-r1 one was a "rushed" release only a few days after the previous 126-pre[2] release, just to fix a critical bug with NO SOUND output on XP machines (and pre[2] was released hours after the initial buggy pre[1] release, to fix an "empty UA" bug, that had many cites refusing to connect...).

... People, sadly, continue to do so now with Supermium/Thorium 32-bit on 32-bit XP SP3 (PAE-patched, a configuration the vendor NEVER supported) and have the audacity to create "issues" in the official trackers: https://github.com/win32ss/supermium/issues/846 IMHO, this type of users are beyond the point of realising they have a "serious problem" themselves...

https://github.com/Blaukovitch?tab=repositories Christian name: Reinhard Residence: Austria (unsure about his descent, of course ) ; the account isn't currently banned, it does appear as the one account that provides bin-patched recent Google Chrome versions Win7-compatible ; but what has already been written about the RAM stands true: I am on Vista SP2 32-bit, BTW, so I've never used myself any of these "cra*ks" ...

... Oops dear Dave , isn't that a contradiction of sorts? ... On Google's Chrome sure, but the Supermium (on which Thorium-Legacy is based on) and Thorium authors have different plans : https://www.win32subsystem.live/supermium/ https://github.com/Alex313031/thorium/discussions/797#discussioncomment-10508470 ... provided, of course, gorhill (or someone else) keeps developing the MV2 uBO implementation...

... In addition to the on-line Contact Form, the "cpuz_readme.txt" file bundled in the ZIP distributions contains a valid e-mail address : CPU-Z Readme file ------------------ Version 2.10 July 2024 Contact : cpuz@cpuid.com Web page: https://www.cpuid.com/softwares/cpu-z.html Validation page : https://valid.x86.fr/ Hall of Fame : https://valid.x86.fr/records.php CPUID SDK : https://www.cpuid-pro.com/products-services.php OT: Luckily for me, v2.10 does launch successfully under Vista SP2 x86 ; whenever I read about an app ceasing to function under WinXP SP3, I fear the same would be true for NT 6.0, because most app authors tend to put Vista inside the same boat as XP ... But in this case it may be the author simply upgraded to a compiler not targeting NT 5.x by default/at all ...

... The Supermium author notified that the "old" --disable-features=UserAgentClientHint cmdline switch will be applicable to his next release, either a third (and final) M124-based one, or the first of an M126-based series (Chromium 126 ESR branch): https://github.com/win32ss/supermium/issues/779#issuecomment-2282969891 https://github.com/win32ss/supermium/issues/779#issuecomment-2287764156

... And just out of the blue, KMB just got an unexpected official update yesterday, Aug 1st 2024: https://browser-download.kfsafe.cn/MiniBrowserSetup.exe The Chinese installer (not recommended to execute directly ) the above URI affords is of version 1.0.0.134, has a digital file signature of 20240801 and comes more than two and a half years after previous official release, 1.0.0.127, which was digitally signed on 20211209... I wasn't able to find any changelog for this release; the installer is 7-zip extract-able, thus I verified the app is still based on the M87 Chromium kernel... @Humming Owl, would you please oblige?

Another Supermium 124 release made it to the GitHub Releases Section: https://github.com/win32ss/supermium/releases/tag/v124 Though it is still labelled as "Pre-release", the author claims it's "the main release of Supermium 124"; among the Release Notes: The distributions bundle (official) progwrp.dll-v1.1.0.5018 ; and before any member of the known "family" asks anew, no, the "not-possible-to-disable-the-CH-API-on-Sm122+" issue hasn't yet been addressed (else, it would surely have been mentioned inside the Release Notes ) ... Kind regards to all ...

... But it did work in my posted test; FWIW, 127 just made it to the Windows BETA channel: https://chromereleases.googleblog.com/2024/07/chrome-beta-for-desktop-update.html The emphasis on my previous post was on "current Cr version", I didn't specify a Cr channel, did I? (... Why is it my distinct impression you just posted with an intent to discredit me? Please, don't answer, since I won't answer back myself...) @66cats: I don't know what to tell you , with the default Cr86 UA I get this (Vista SP2 x86):

Hi Dave ; I wish I were over at your part of the planet, where you currently have a pleasant 18C, while here we're in the middle of a never-seen-before July heatwave, about to last at least until the 27th (to get an idea, it's 23:34 now and the outside temp is at 35C ! ) ... Back on topic: Your ex-colleagues are simply blocking the version of 360EE you're using (on XP) due to the User-Agent-String it broadcasts; I suppose you're using one of the @NotHereToPlayGames's mods, so inside its loader you'll find the cmdline switch below: --user-agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36" They outright block Chromium 86, so when the browser tries to load that page, it gets served an "errorcode337" and the tab ends up blank... This is a bad practice altogether, since Cr86 is perfectly capable of loading+rendering that site; to circumvent their block, just spoof a current Cr version: --user-agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36" ... and Bob's your uncle: ... Might I also add that the page has a sub-optimal web design, not fit for desktop browsers and without any consideration for older, low on resources, hardware (e.g., it contains in its top part a constantly animating huge video/gif that consumes far too many CPU cycles on OSes without native H/W decoding, via GPU) ... Apologies for the rant, cheers and best wishes ...

... Do you have to be signed-in for this "bug" to occur? FWIW, replicating the search you referenced for that same item ("Shimano CS-HG41") with last WE's St52 (32-bit) build proceeded normally, as displayed below: Apologies if I'm missing something and "your" bug is actually a different one ... BTW, are you on a SSE-only CPU?

Hi Dave ; I think a distinction should be made, so that other readers aren't being confused ... The "wrapper" library component of Supermium (which the Thorium author has also got permission to bundle with his browser, to make it XP+Vista compatible) comes originally from win32ss (win32 here at MSFN), it consists of only one DLL (named progwrp.dll) and the file version is currently in the 1.1.0.xxxx range... As you wrote already, the installer for Sm-v124-pre comes with v1.1.0.5016; that one apparently causes issues for some non-standard XP SP3 x86 installations, hence GitHub #686 was filed; inside that thread, win32ss has uploaded, as of this writing, six (6) iterations of progwrp.dll-v1.1.0.5017 and one (first) iteration of progwrp.dll-v1.1.0.5018 here which, technically, is the latest official offering ... OTOH, versions 1.2.0.xxxx belong to the alternate, let's call it "unofficial", "wrapper" library implementation by @IDA-RE-things ; at this time, this implementation consists of up to 3 separate DLLs and is mainly targeting Low-End (as in H/W) XP SP3 x86 older setups (slow HDDs, limited RAM, slow by today's standards CPU, etc.): https://github.com/IDA-RE-things/Chrome-xp-api-adapter/releases As posted by 66cats, the latest version of this alternate lib is 1.2.0.5065 ... Judging by your own (relatively powerful) H/W Dave, do you really need to use this alternate implementation? Can you spot noticeable differences between official 1.1.0.5018 and unofficial 1.2.0.5065 ? Cheers ...

... Read these GitHub comments, if one's after the x86 binaries: https://github.com/win32ss/supermium/issues/686#issuecomment-2183203030 https://github.com/win32ss/supermium/issues/686#issuecomment-2183230334

... Let me remind readers of this thread that the actual issue discussed here has been already reported to UXP-"upstream" (i.e. MCP: Moonchild Productions) by @UCyborg some three weeks ago: https://forum.palemoon.org/viewtopic.php?f=62&p=251950&sid=14291391b8552d3afe8f153cf401c56c#p251950 but. as you can probably see for yourselves , nothing has even budged there so far ...

... A more in-depth analysis of the term: https://en.wikipedia.org/wiki/Portable_application A "portable" app installation is also called "stealth" when the portable app is being launched from an external (to the host) storage media (e.g. HDD) but when the app is exited and the media detached from the host computer, NO TRACE whatsoever related to the app is left on the host's file system and registry; I guess you can also call the app "stealth" even when "installed" on an internal (host) disk, when it doesn't leave any of its 1. associated files outside of its assigned "portable installation" directory 2. associated registry keys on the host OS once exited... Many apps can be made "portable", but it takes a lot of effort to additionally make them "stealth"; sometimes, that isn't possible at all, even with app virtualisation (e.g. Microsoft Office and most of the Adobe Suites); in those difficult cases , the application is very complexly intertwined with the OS it runs on ...

https://www.virustotal.com/gui/file/96585bab134e3011bb25b7310243e5d384575e76408fb8adfd036f045b1013a0/detection BTW, this is with latest Supermium 122-R6 32-bit release ...

Good News for Windows XP SP3 users ? https://www.patreon.com/posts/lsc-application-105275497

... Would you be so kind as to enlighten me/us towards that very goal? I have a vested interest myself into making this work in latest Th/Sm (Chromium-122 based), but: Google have long ago removed any CH-related flags from within "chrome://flags/"; I am aware of the "--disable-features=UserAgentClientHint" command line argument, but it appears it no longer works for Chrome 122 ... That same flag currently works as expected with KafanMiniBrowser (Chromium 87 based), which had a "draft" CH implementation; I used the test site: https://user-agent-client-hints.glitch.me/ and KMB indeed leaks its Chromium version (87) through CH: But launched with "--disable-features=UserAgentClientHint" it doesn't: OTOH, latest Thorium 122 (.169) 32-bit SSE3 with the same cmdline argument continues to leak its Chromium version (122): This is rather unfortunate because at least one of my UA-spoofing extensions (Custom UserAgent String v0.2.3) in Th122 fails to work properly on some sites (which take into account the Chrome version sent via CH and not the one via the "classic" UA-string spoofed by the extension) ... I'm not entirely sure, but I think the "flag" used to work with Supermium 121, but now it doesn't with either Th/Sm 122 ... If anyone can come up with a tested/working solution for these, please chime in (FWIW, a cursory web search on Google did not produce a way to fully disable ClientHint in recent Google Chrome versions ) ...

When I follow the link in that post, it leads me to another post discussing the Modify-HTTP-Response addon. No userscript there. ... The userscript I mentioned is inside the body of the exact MSFN post I (searched and) linked for you ; if clicking the link above doesn't get you exactly to: ... then something's gone awry in your browser's behaviour ...

... Discourse-based forums fixing userscript below: https://msfn.org/board/topic/184051-my-browser-builds-part-4/?do=findComment&comment=1258499 ... and a revised version of the uBO (legacy) custom filter having the same effect : https://msfn.org/board/topic/185966-my-browser-builds-part-5/?do=findComment&comment=1258536 NB: Both above mitigations are "universal", whereas the Modify-HTTP-Response based solution you opted for (it was the recommended solution on the official PM Forum at a time the UXP platform was missing support for those villainous operators, "?." & "??" ) requires manually modifying its "filter" every time you come across a discourse forum NOT covered already by the filter's existing RegExp... ... Are you saying you tried to properly use the editor's code tag (</>), select Javascript under coding language options, paste the "code" inside the designated input field and when you hit the "Insert into post" button the "Forbidden..." error popped up? Or was it that the code was properly inserted into the post while in Edit/Preview mode and the error hit after you clicked the "Submit Reply" button?

Nah... "They" were "bad" to begin with ... Updating their code frameworks to target Google Chrome 125+ (which "they" expect every single one of their users to be on at the moment ) is what distances all these services further away from what UXP can (reasonably) digest ...

... You're using St55, so the wording there (about:profiles) is still "Restart with Add-Ons Disabled" ; in St52, MCP have reworded that to "Restart in Safe Mode", to more accurately indicate what happens when you click that button... As you've found out already: "Restart with Add-Ons Disabled" != "disable every add-on manually and restart" http://kb.mozillazine.org/Safe_Mode

https://forum.palemoon.org/viewtopic.php?f=62&t=31185 ... Probably for the best that you did not detail there how this "came into your awareness" ; "MSFN" and "VistaLover" strings would have triggered many "alarms" in the official PM forum ; what's of concern, though, is that no-one there has acknowledged the issue so far; FWIW, I would've posted this in a more "visible" subforum like Web Compatibility Support ... Take care ...

Hi ; In the past, I have politely asked you to put some more effort into improving the quality of your problem reports, but it appears I can't get the message through ; indeed, "one picture is worth a thousand words", but in this case it's far from it... Please, provide "clickable links" of the actual problematic URLs and also try to include English translation(s) of the error(s) your Russian-localised OS generates ; if the errors you encounter are manifesting themselves ONLY when being logged-in, few here (including the developer) without a proper account already will go into the trouble of registering just to troubleshoot your errors ... As a rule of thumb, social media portals, be it western (e.g. Facebook) or eastern (e.g. VKontakte) are relentless towards anything "legacy", i.e. H/W, OS, browser; they're veritable beasts of Javascript and CSS that put a heavy tax on older desktop machines; I avoid social media with a passion, but if "one" must use them, better limit "oneself" to a mobile device with a recent version of Android/iOS... Small rant aside , I launched latest NM28 [v28.10.7a1 (32-bit) (2024-05-23)] and tried to load: https://vk.com/megaslava The browser struggled for a few seconds (5-8s) while trying to render huge blobs of code , but in the end the URI was successfully displayed: As a further test, I reloaded that same URI ten (10) consecutive times, not once did I get anything similar to what's contained in your first screenshot ; as I don't have a VK account myself, I only tested as an anonymous VK user ... As for your second screenshot, it would appear VK use serviceWorkers, so in "about:config" just enable them (if not already): dom.serviceWorkers.enabled;true FWIW, I didn't get any of the errors depicted in your second image, probably because I'm not being logged-in ... My friendly advice to you: If you can, use one of the XP-compatible Chromium derivatives for VK.com (and likewise for other "offenders" like Instagram/X/Youtube etc.) ... Regards.

Breakage of discourse-based forums/communities under UXP-based browsers (NM28/St52 and probably St55) is an already known issue, that has been reported more times than I'd care to remember ; discourse serve a script that checks for a specific platform feature in the client browser, which isn't present in the UXP platform per se but, at the same time, isn't strictly necessary for the discourse-based forums/communities to function properly - thus, "their" browser-checking script categorises UXP-based browsers as "unsupported" and then "they" serve the "dumbed down" version of the forums ... I have offered two mitigations for this predicament, one based on a custom uBlock Origin filter and another in the form of a userscript (requires a userscript manager to be installed); search my MSFN posts with the keyword "discourse" ; probably inside "My Browser Builds (Part 4, 5)" megathreads...