VistaLover
Content Type
Profiles
Forums
Events
Posts posted by VistaLover
-
-
1 hour ago, Mathwiz said:
I'm kind of astonished by the design of this Web site.
Am I correct in concluding that, rather than using the .pdf viewer built into every major Web browser,
they coded their own? In Javascript? Why would anyone do this?It can't have been done to support very old browsers that might lack a built-in .pdf viewer, because the Javascript relies on new constructs that require polyfills even on Chrome 86. Older browsers don't stand a chance.
... 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
:
1 hour ago, Mathwiz said:I just tried to open the .pdf in Acrobat 9 and was told that I need a newer Acrobat version!
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
...
2 -
18 minutes ago, Anbima said:19 hours ago, NotHereToPlayGames said:
You do not need an online viewer to view .pdf's - download it then drag and drop into 360Chrome, bypass that "viewer" -- https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf
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
:
3 -
On 2/24/2024 at 12:48 AM, roytam1 said:
... 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!
2 -
On 2/22/2024 at 4:20 PM, AstroSkipper said:
WinSCP 6.1.2 is indeed the last XP-compatible version.
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:
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...
3 -
3 hours ago, ED_Sln said:
Solved the problem with monochrome emoji on Windows 7 and display emoji on Windows XP using Twemoji for chrome extension.
https://chromewebstore.google.com/detail/twemoji-for-chrome/fopgafjdjlongoeblobbafbnapafcicg
... 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
5 -
8 hours ago, Ascii2 said:
Presumably, the "status-4-ever" component you refer to, is the Moonchild's "Pale Moon status bar" extension (a fork of Sparky Bluefang's "Status-4-Evar" extension) that was bundled as an extension with Pale Moon through the end of the 26.* series. As of the 27 series, the extension was no longer included as such with Pale Moon, but instead was incorporated in a different manner.
Exactly!
8 hours ago, Ascii2 said:I checked roytam1's build offerings at
https://o.rthost.win/palemoon/index.php?sort=date&order=desc
, but did not find the New Moon 20220812 build that you mentioned
that you believed was the last build that contained the fully working mentioned component.
Please verify the build and report."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
2 -
9 hours ago, we3fan said:
Apologies if Chrome and Win 7 are OT here
... 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 
...
2 -
@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) ...
22 hours ago, Jody Thornton said:I really thought that New Moon 27 was just Pale Moon 27 modified to run on XP and Vista,
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
...
22 hours ago, Jody Thornton said:Sometimes we also just forget
... Tell me about it
... Old(er) age is a b*tch 
...
22 hours ago, Jody Thornton said:I don't need to know how my toaster works
... 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?
22 hours ago, Jody Thornton said:I DID realise that newer releases kept the 28.x versioning, though, in fairness to myself, I DID go and look in the first posts of this thread, where we're told that was explained, and I didn't see that explanation
... well, sorry to say it, but you didn't look well
:
On 1/20/2024 at 1:14 AM, roytam1 said:Q: Why you still keeping on version 28? will you have a version 29 build?
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...
1 -
On 2/15/2024 at 2:38 PM, Egorkaru said:
still does not work in Serpent 52 and New Moon 28 browsers
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?
On 2/16/2024 at 10:20 AM, Egorkaru said:a redirect occurs to a stub page about an unsupported browser:
https://web.telegram.org/a/unsupported.html... 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...
On 2/16/2024 at 10:20 AM, Egorkaru said:from two errors in the console:
QuoteContent Security Policy: Couldn’t parse invalid host 'wasm-unsafe-eval'
Load denied by X-Frame-Options: https://web.telegram.org/a/unsupported.html does not permit framing.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.
4 -
19 hours ago, reboot12 said:
The change OS value Windows NT 10.0 to Windows NT 5.2 in UA probably helped:
Mozilla/5.0 (Windows NT 5.2; rv:120.0) Gecko/20100101 Firefox/120.0
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
...
20 hours ago, reboot12 said:Thanks for showing interest
... And you're most welcome
...
4 -
14 hours ago, modnar said:
Good point about Googl-isation and it's a nasty thing, in my opinion largely caused by Adobe's incompetence (?) to keep Flash together
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
...
4 -
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...
10 -
Just now, nicolaasjan said:
Does that also include security fixes?
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...
9 minutes ago, nicolaasjan said:I don't read the changelogs here that often.
... Tsk, bad on you, dear friend
...
Best wishes
3 -
On 2/17/2024 at 8:42 PM, modnar said:
the NewMoon 27 (the "standard" one),
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 ...
11 -
20 hours ago, VistaLover said:
Which SSUAO value did you in fact use there? Was it the Fx-120 one or the "just Chrome" one
?
8 hours ago, reboot12 said:I added UA in about:config > general.useragent.override.elektroda.pl
Mozilla/5.0 (Windows NT 10.0; rv:120.0) Gecko/20100101 Firefox/120.0
... 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
...
1 -
On 2/14/2024 at 4:00 PM, reboot12 said:
It worked well for several hours, but this message finally appeared again - Secure Connection Failed
... 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.
2 -
On 2/18/2024 at 3:37 AM, mina7601 said:
52.9, not 52.6.
... 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
3 -
5 hours ago, 66cats said:
What am i doing wrong?
...
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...
0 -
On 2/14/2024 at 2:07 AM, Milkinis said:
is it me or the legacy store is gone for good ?
the ''visit legacy store'' button does not take effect
... Please, read this
...
Best regards
!
2 -
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:
QuoteThis version of the Chrome Web Store will be discontinued in January (2024). Visit the new store now.
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:
QuoteTo add this item to Chrome, please update your browser or visit the legacy store. Visit legacy store
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) ...
4 -
On 2/6/2024 at 1:55 AM, AstroSkipper said:
@VistaLover Do you have any more in-depth information on the startup cache in Firefox-based browsers
or links to corresponding documents? I can't seem to find anything like that.On 2/10/2024 at 8:29 PM, AstroSkipper said:Even my request in @roytam1's browser thread also went unanswered. It seems that nobody here really has more information or knowledge about the startup cache and how the browser restart affects this cache.
... 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
QuotestartupCache
Precompiled startup cache stored in a startupCache.4.little file. Not clear what it caches other than system font data, but some Firefox add-on developers delete the equivalent file in a Firefox profile while developing add-ons.
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
Quoteon Windows, this "fastload" makes development *suck*! I have to delete "startupCache.4.little"
every time I restart my browser to test changes I did in my addon.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.
3 -
7 minutes ago, mina7601 said:
and I was talking about the current Adblock Plus from its homepage
https://adblockplus.org/en/download
for my browser Chrome on my Windows 11, not the legacy Adblock Plus for roytam1's browsers,... 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 :
On 2/12/2024 at 8:26 PM, nicolaasjan said:uBO (web extension version) can strip these parameters.
- AdGuard URL Tracking Protection (built in)
- Actually Legitimate URL Shortener Tool; from:
1 -
14 hours ago, nicolaasjan said:
why don't you try uBO?
... 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)
...
2 -
1 hour ago, UCyborg said:
... 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
3
ArcticFoxie/NotHereToPlayGames -- 360Chrome v13.5.1030 Redux
in Browsers working on Older NT-Family OSes
Posted · Edited by VistaLover
... 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)