Jump to content

VistaLover

Member
  • Posts

    2,084
  • Joined

  • Last visited

  • Days Won

    93
  • Donations

    0.00 USD 
  • Country

    Greece

Everything posted by VistaLover

  1. As an addendum to my previous post, Mozilla do host (on GitHub) "on-line" editions of their PDF.js lib, one targeting "current" browser engines: https://mozilla.github.io/pdf.js/web/viewer.html and another targeting "legacy" browser engines: https://mozilla.github.io/pdf.js/legacy/web/viewer.html Neither of the two works on Ch86/87-based browsers (and on St52) to display the "C0801E.pdf" file, https://mozilla.github.io/pdf.js/legacy/web/viewer.html?file=https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf https://mozilla.github.io/pdf.js/web/viewer.html?file=https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf while BOTH do when loaded in Ch121-based latest Supermium-v121-hf ... Yes, the browsers "we" use here are more "legacy" than what Mozilla even thought of ...
  2. ... Indeed ; as the web console portion of the first image I posted previously reveals, the "enganchesaragon.com" site are self-hosting v3.0.279 of the pdf.js library; according to the GitHub repo for it, tag 3.0.279 was cut on 2022-10-29 ; ... The library inside the latest Serpent 52 build is of version "1.7.348-git-754c4bd", committed on 2017-03-04, i.e. 5 1/2 yrs older (!) ... It would then seem that v3.0.279 (from 2022) requires platform features not fully compatible with UXP ... I'm uncertain as to how to proceed to find the version of the pdf.js (equivalent) lib inside 360EEv13.5 and/or KMB; Chrome 86 stable was released on 2020-10-06, 87 stable on 2020-11-17; Google probably don't use the same lib Mozilla maintain ; as discussion here has proved already, Ch86/87 (autumn of 2020) don't support the much "younger" Mozilla pdf.js v3.0.279, that came two years after those browsers were released... After my analysis, one "probable" answer why "enganchesaragon.com" choose to self-host an instance of the Mozilla PDF.js lib to display the PDF files "they" serve is: "They" prefer it over the native-PDF-viewer implementation on users' (mostly Chrome-based) browsers... Don't know what else to think of ...
  3. ... Couldn't agree more ; but, "no sense" is probably only "applicable" to frequenters of these threads, on "legacy" browser engines ; I can assure you that the web designers of that Spanish site did NOT, even for a mere second, think of "backwards compatibility" ; they're probably "trained" to expect each and every eventual user of their service to be running the latest Chrome/Firefox/Safari, where the original "issue" you reported (and generated many additional posts here) is simply non-existent - it works right away and the user "there" doesn't notice any issue; he/she just moves on with the browsing; the comparison between "sensical" and "non-sensical" never crosses his/her mind ... It is us here inside the MSFN "older OS" forums who harbour a mentality of being "the centre of the IT universe", whereas, in fact, we're just one dying old star which has practically extinguished all of its fusion-able material ...
  4. OT ... I use a userstyle for that : @-moz-document domain("msfn.org") { body.ipsApp article.ipsComment div[data-quotedata*='roytam1'] div.cPost_contentWrap p { max-height: 300px !important; overflow-y: auto !important; } } ; I've named it: msfn.org @roytam1 "long" posts fix ...
  5. ... The "more" correct way to do it is: 1. click the code button (</>) in the MSFN editor toolbar 2. In the opened popup, change the code syntax to "Javascript" (bottom right) 3. Paste the code (you copied directly from TM) in the main box 4. Click the "Insert into post" blue button 5. (Optional) Preview your embedded code (far right button of the MSFN toolbar)
  6. ... Indeed (and pardon the slight OT ), the "online-PDF-viewer" URI: https://storage.enganchesaragon.com/public-websites/ecommerce/pdf_viewer/web/viewer.html?file=https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf does load in last week's Serpent 52, but the pages are rendered blank there : If one downloads directly the PDF file via: https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf (it's 10.4 MiB in size) and then tries to view it in St52, all's fine : Yes, the PDF file specs have evolved over time and full backwards-compatibility isn't guaranteed ; the file in question is of version 1.7 and I had better luck than you in that it opened in my Adobe Reader X (aka 10) copy: Though, do note that it is stated in the above screenshot that PDF v1.7 should be compatible with Adobe Reader/Acrobat 8.0+, so there may be something off in your case ...
  7. That's how I've been doing it so far. But I thought it might be easy to get around this. One other approach I use myself is to let the browser handle itself the online PDF files (without a prior download to disk and then drag-n-drop ) and display them via its native PDF viewer; however, in the case discussed, https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf the file has an "attachment" content-disposition and loading that URI will generate a "Save File" download prompt; that's why I have also installed: https://chromewebstore.google.com/detail/undisposition-racle-fork/bbppejejjfancffmhncgkhjdaikdgagc and I enable it as needed - you want the older v0.0.4, which is still at MV2, for 360EE... Below is KafanMiniBrowser loading the referenced PDF URI in its default viewer, via "undisposition" extension :
  8. ... This is probably just a simple oversight , but these two packages are being served through plain HTTP, while the page they're on (MSFN) is served through HTTPS ; recent Chromium versions block by default such scenarios as "mixed-content" and won't let you download the files out-of-the-box (a security warning is issued, can be ignored/overridden at user's discretion); I experienced this myself as I was testing latest Supermium-v121-hf-x86 on those links... Not a big thing , but perhaps the links could be edited to HTTPS, too (as are all the links to the rest of this weekend's packages ) ... Many thanks!
  9. Interested members can find needed files on SourceForge: https://sourceforge.net/projects/winscp/files/WinSCP/6.1.2/ The "WinSCP-6.1.2-Portable.zip" is the one you need under WinXP (unpack and launch the .exe file); the problem arises if you want the app localised , because that zip archive ONLY comes with the default, en-US, locale (embedded into the .exe) . The installer, "WinSCP-6.1.2-Setup.exe" comes with multi-language support, but it's built with an InnoSetup version that requires at least Win7 . To get the localisation files out of it you need use a tool capable of extracting Innosetup installers; my two "loved-ones" are just CLIs, innounp (at v0.50) and innoextract (at v1.9) ; however, if you are a GUI type, you can use the much larger app UniExtract2, which contains those two above CLIs as internal components (this extracting "suite" has been mentioned and linked before by AstroSkipper). Once you have successfully unpacked "WinSCP-6.1.2-Setup.exe", you should have access to a "Translations" dir, with numerous "WinSCP.*" files; pick the one that has a file extension denoting your desired locale (e.g., for German it should be "WinSCP.de") and place that adjacent to the WinSCP.exe main executable inside your originally unzipped "portable" archive; launch the app (it'll still be in English) and through the app's configuration (Options -> Preferences -> Environment -> Languages) you can now select your preferred locale: An app restart is then required for the change to take effect ... If you don't mind your "portable" app being in the much acclaimed PAF format, the people over at "portableapps.com" have prepared a "special package just for XP users", who have now been deprived of future WinSCP updates: https://sourceforge.net/projects/portableapps/files/WinSCP Portable/WinSCPPortableLegacyWinXP_6.1.2.paf.exe/download That package has all available localisation embedded ... PS (and OT): This time, the WinSCP devs did not put Vista SP2 32-bit in the same boat as WinXP - the latest release as of writing this, 6.3.1, again via the "portable" distribution, launches and runs fine there () ... Just as a FYI...
  10. ... Yes, thanks, this solution was already pointed to inside Sm's GitHub issue tracker some 6 weeks ago : https://github.com/win32ss/supermium/issues/134#issuecomment-1883249689
  11. Exactly! "20220812" is the buildID of the 32-bit, xpmod (i.e. capable of SSE2+), build; buildID is listed inside "about:" and "about:support" ; the corresponding "released" package should be the one with a close "git-date", most probably: palemoon-27.10.0.win32-git-20220813-042db568fd-xpmod.7z
  12. ... Well, Win7 is certainly "On Topic" here, because the roytam1 forks (browsers and other apps) do work under that OS; after all, despite its users not wanting to admit it, Win7 is by now an "Older NT-Family OS" ... However, and this is just me , "extensive" references to the Chromium forks (compatible with said "older NT-family OSes") should be better posted in the dedicated threads (we have enough already...) ; I don't exclude myself here , I've often fallen foul of this before ...
  13. @Jody Thornton : No worries, we're good ... You're right, nobody "twists my arm" to make long-winded posts here, but in your case I did provide replies to your queries because I thought you deserved the replies - also, this is material that, no doubt, will be of interest to other members here (and see, roytam1 pinned it to the start of this thread) ... A correction on a technicality there: "official" Pale Moon 27 had native support for Vista (the 64-bit variant had some glitches with media playback - only recalling from memory, because my Vista OS is 32-bit), so NM27 by roytam1 only had to re-instate WinXP support ... ... Tell me about it ... Old(er) age is a b*tch ... ... Neither do I, but I'm the type of person that first reads the toaster's manual (if it comes with one ), and only then do I plug it to the mains; do you get my drift? ... well, sorry to say it, but you didn't look well : Linked Answer: https://msfn.org/board/topic/182647-my-browser-builds-part-3/?do=findComment&comment=1199724 If I'm being asked (once) again , the decision back then was made based on uncertainty on how several, then popular, Firefox extensions would behave under an application with version 29.0+; it was a time when "upstream" (spearheaded by M.A.T.) wanted to completely remove ALL support for Firefox-specific extensions and move solely to PM targeting ones (in fact, they did do that for a while, didn't they?) ... The transition from v28.x to v29.x was crucial for Mozilla Firefox, because Fx-29.0 came with radical internal and external changes, collectively known as Australis (which, contrary to public belief, wasn't just a change in GUI); many Firefox extensions of that era, to keep backwards compatibility, had different sets of internal code to cater to Fx <=28 and Fx >=29 at the same time, so using such an extension on NM29 (with a Fx-28 type of GUI/engine) was just asking for trouble...
  14. Greetings ; what do you mean by "still" ? Was it working in UXP-based browsers and then stopped? How long ago was that? Have you already reported that breakage in the past and you now feel disgruntled the issue remains unresolved? Please be aware that UXP, as a platform, is not very good at supporting these so-called web (in-browser) editions of popular chat/messaging applications, which are usually optimised for recent Chromium-based browsers (or just for the browsers on your mobile device ) ... Such web-compat issues are usually for "upstream" (MCP) to address, but if one asks "there", the standard answer from "them" is: "Use the dedicated Windows application"; this is, of course, no consolation for XP/Vista users, because most of these apps now require at minimum Win7 (soon to be Win10 ?) ... Searching in the PMForums, someone there suggested using a "legacy" URI of the form: https://web.telegram.org/?legacy=1#/login , does it still work on you for log-in purposes? ... In my "dirty" St52 profile, all I get is a white/empty page inside a thin-lined black frame , much like what @mina7601 has already posted... It would appear the most important clue inside the Web Console simply eluded you ; the page deploys a script which performs browser-feature checks: https://web.telegram.org/a/compatTest.js UXP then fails those tests , because it doesn't, yet, support "Intl.DisplayNames", a JS feature which was first implemented in Fx-86/Ch-81: It just so happened that "upstream" (MCP) have opened a UXP issue for that just 6 days ago, but so far it hasn't received any activity ... A polyfill for that missing function already exists ; my JS-coding skills are non-existent , but I tried to make a userscript out of it (and inject it through Violentmonkey), problem being the script gets quite large when you add all the needed "locale.data" ... Another issue is that, during my tests, I discovered that for the userscript to work on "telegram.org", one has to globally disable CSP protection in the browser, which. in itself, is a security risk ... FWIW, with my basic "polyfill-as-userscript" and CSP (temporarily) disabled (security.csp.enable;false), the offending web page finally loads: I don't own a mobile device (yet anyway , by my government has other "plans" for its subordinates ), nor do I have an account with Telegram, so my experiments ended just there ... Kind regards.
  15. Hi again ; I can't see myself how that could've helped , because Fx-120.0 is incapable of running under NT 5.2 (Windows Server 2003 x86 ?); with the above UA, you're just "sticking out like a sore thumb" ; still, stranger things have happened in the world of IT... Also, if elektroda are adamant on supporting only the latest Mozilla Firefox version, pretty soon you'll have to spoof Fx-123.0 ... ... And you're most welcome ...
  16. Like you, I do agree that Adobe Flash Player, despite being closed-source, was a good technology for its time and served well XP/Vista users running the OS under era-correct H/W; it came embedded with patented decoders and worked quite well with most GPUs of the era... But it wasn't deprecated due to "Adobe's incompetence", nor was this related to just Google pushing their ways... FWIW, a localised version of Flash is still being used in mainland China, maintained by a Chinese Adobe affiliate... As Microsoft moved away from XP (and Vista) and introduced new media playback technologies inside the Windows OS itself (e.g. Windows Media Foundation, WMF, which matured in Win7), and with newer WinOSes requiring more "advanced" H/W (GPUs/CPUs/RAM) to run properly (but through which, higher-spec'ed, H/W native playback becomes "attractive"), browser vendors saw it proper to move away from NPAPI/PPAPI Flash into HTML5 native playback, inside the browser; Adobe Flash had been notorious for many serious vulnerabilities during its lifetime, so for many computer users the deprecation of Flash was a blessing in disguise... Google was not the only browser vendor in favour of the migration, in fact Apple had a bigger role in this ... I can understand, though, that the deprecation of Flash and the general move to HTML5 media playback has left XP users on older/under-resourced H/W at an impaired/handicapped state.... But when I talked about the "Googl-isation" of the web, I did not have the deprecation of Flash (and NPAPI in general) in mind; I meant the current trend of Google web devs constantly "devising" new "dialects" of the Javascript programming language and them, via their undisputed dominance on everything-web, leveraging these new JS iterations into the web standards; these, even when still at "draft" status, are pushed to the newer Google Chrome releases and, as a result, become also adopted by the web-frameworks that are part of most contemporary web sites; sites that, unlike the good times of the past, aren't just comprised of pure HTML pages, but are instead monstrous blobs of JS+CSS code that has to be downloaded and rendered locally by the browser engine, putting a heavy tax on your H/W... Thus, Google make sure that "the web" will break on other "legacy" web engines and also make sure that "the web" will underperform on your older H/W - IOW, "they" try their best to make your old "setup" practically no longer capable of any more use ... People who follow me here know that I'm not a coder/web developer, so it's possible some of my wording above was not well chosen; but I'm sure you all get the gist of it ...
  17. Dear Jody, and I mean this in a genuine way , you of all people shouldn't come back with the very same queries, because it was I who answered your similar queries in the not so distant past... What it all comes down to is: 1. do you have a grasp of what open source code is? 2. do you have a grasp of what a forked open-source code repo is? 3. do you have a grasp of what a platform and an application built on it is? If not, any answer you'll get from me won't make much sense to you, and I'm sorry to say that there's no simplistic yes/no answer to your re-iterated queries above... MCP maintain the official UXP application platform, its repo is hosted below in: https://repo.palemoon.org/MoonchildProductions/UXP/ There are several branches in that repo, main ones being master and release MCP maintain the official Pale Moon browser application, its repo is hosted in: https://repo.palemoon.org/MoonchildProductions/Pale-Moon/ Again, the two more important branches in that tree are master and release The official Pale Moon releases are being issued at least once a month, compiled from code from the UXP release platform branch and PM release application branch. Likewise, Basilisk-Dev maintains the official Basilisk browser application, its repo hosted in: https://repo.palemoon.org/Basilisk-Dev/Basilisk/ Two branches of note there, too; master and release The official Basilisk releases are being issued monthly, or as the dev's time permits, compiled from code from the UXP release platform branch (by MCP) and the Bk release application branch. OTOH, roytam1 maintains a somewhat different development scheme; he maintains a code "smorgasbord" below: https://github.com/roytam1/UXP This is a fork of the official UXP platform repo (see above); the tracking branch of that repo follows more closely the master branch of the official UXP platform (see above); the forked UXP repo, by now, is different to the original one in various ways, one of which is in restoring WinXP+Vista support (which also entails several lib differences, like in ffvpx), another one is keeping Mozilla features MCP have dumped long ago (e.g. Web Extensions, Tab Containers, half-baked e10s code, EME, e.a); also, the NSS lib in "our" browsers is somewhat different to the one MCP maintain; that is why profiles between the official apps and roytam1 apps aren't 100% interchangeable... The UXP repo by roytam1 also encompasses application-specific code, ported from the official PM master branch and the official Bk master branch, again chosen selectively (i.e. not all Pale Moon features end up in NM28, not all Bk features end up in St52, but most do). The custom branch of roytam1's UXP repo holds the code snapshots that get compiled weekly to produce the NM28 and St52 releases; if you're still following: It's difficult to directly compare the official releases to the roytam1 ones, because the first follow a different code development scheme + release schedules, but indeed all the vital code parts (features, bug/security fixes, etc) from the former find their way to the latter, sooner or later... As a rule, based on what I detailed above, the "latest NM28 release" should contain all the "applicable" platform/app code found in the last PM release, and then some (i.e. code in the official master branches authored after the release was cut) ; likewise, the "latest St52 release" should contain all the "applicable" platform/app code found in the last Bk release, and then some (i.e. code in the official master branches committed after the release was cut - on that note, it's sad that Basilisk-Dev has admitted elsewhere that he's withholding on purpose to publish Bk code in its master branch until "the very last moment", so that "we" here be incapable of using it "ahead of time"...). The only exception to the above is when "upstream" collectively (MCP/Basilisk-Dev) make a "mid-week release"; in that case, the builds released by roytam1 on the Saturday that immediately follows those mid-week upstream releases will have "caught up with them", so to speak... Jody and others, please bookmark this post and revisit it as needed, so that I don't get asked the same things again and again - and no, one "can't have one's cake and eat it, too"; if one wants to keep using "these" browsers, one must also "keep in touch" with how things are developing "here" ; the issue of "precious personal time" has come up many a times in the past, but be sure I'm just a volunteer here, my personal time is as precious (to me) as is yours... PS: Changelogs are NOT confusing, if one ever made a simple effort to understand what they do represent; they're made of git-commits between the previous and the current release, often times they're identical to the "upstream" commits they were ported from; so one can easily verify how far ahead of (or behind of or different to) the upstream code the current release happens to be...
  18. These come via the platform (UXP) "updates" and are being implemented (when possible) by MCP himself (who has private access to them through Mozilla); if they're uploaded to the official UXP repo, then sure they'll be integrated/backported to Roy's fork of UXP (off-the-top-of-my-head, last summer's webp vulnerability was also patched "here"); be advised that a large number of Firefox "security fixes" involve e10s, as that isn't implemented in UXP, they won't make it onto "our" browsers... ... Tsk, bad on you, dear friend ... Best wishes
  19. 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 ...
  20. ... 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 ...
  21. ... 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.
  22. ... 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
  23. ... 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...
  24. 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) ...
×
×
  • Create New...