VistaLover

This is indeed correct - most UXP-based browsers are now natively supported in palefill's install.rdf file; it's only Serpent 55 that isn't: https://github.com/martok/palefill/issues/25#issuecomment-1157015223 @Mathwiz is mainly using St55, so perhaps got confused and assumed this is still the case for UXP-based browsers ...

This isn't true ; with the last (semi-)official release (v.1.2.19) of github-wc-polyfill prepared by SeaHOH, the GitLab link posted has no problem fully loading in my latest Serpent 52 copy (manual modification of 1.2.19's install.rdf is required to allow installation in St52): NB that SeaHOH has abandoned further development of github-wc-polyfill, but our own @roytam1 has provided (at least two) updated XPIs for it in below "upstream" issue #68 thread: https://github.com/JustOff/github-wc-polyfill/issues/68#issuecomment-1218104421 So one should install v1.2.19.2 now to keep up with GH's shenanigans ... OT: MSFN's post/comment editor is overly problematic today, I find ...

... Well. most application authors currently behave like sheep , blindly (no offence meant, BTW ) following ONLY what Microsoft supports at the time they release an update for their app... My gut feeling is they didn't go for DirectX 11.2 specifically, rather they dropped support for previous DirectX versions, as these are to be found in OSes MS no longer supports (free of charge, as in not ESU ) ...

... Why would you be off-topic if your query pertains to Serpent 52.9.0 ? Well, here's the long story of it: My complete theme is called Photonic and it was created by Lootyhoof, a member of the upstream MCP dev team, who specialises in Complete Themes for the Pale Moon browser! Photonic had originally support for both Pale Moon (which has a pre-Australis default theme) as well as support for (official) Basilisk (which has the Australis GUI). As such, it was hosted in both https://addons.palemoon.org/themes/ (where it still is) and https://addons.basilisk-browser.org/themes/ In late January, Moonchild halted further development of Basilisk; in May, Photonic was removed from: https://addons.basilisk-browser.org/addon/photonic/ (archived snapshot: https://web.archive.org/web/20220511055801/https://addons.basilisk-browser.org/addon/photonic/ ) Lootyhoof continued the theme's development, but he removed Basilisk support in versions > 4.0.0... The source code repo for Photonic is: https://github.com/Lootyhoof/photonic A no-longer-maintained mirror is: https://repo.palemoon.org/Lootyhoof/photonic The easiest way to get the last Basilisk-compatible version of Photonic is via GitHub: https://github.com/Lootyhoof/photonic/releases/tag/v4.0.0 But (there's always a "but" for us on "unsupported" OSes+forks), getting that XPI is NOT enough, sadly... As you might know already, (official) Basilisk is meant to run on Win7+, so Photonic's author made sure to use Win7+ specific CSS code during its development ; many of its internal CSS scripts have the below code: @media (-moz-os-version: windows-win7) { which makes sure the theme (is designed for and) properly runs at minimum on Windows 7, only! Additional specific code @media (-moz-os-version: windows-win8) { and @media (-moz-os-version: windows-win10) { configures the theme on Win8/8.1 and Win10 - there's absolutely no provision for the theme running under XP and/or Vista, which are the target (i.e. most frequently used) OSes for Serpent 52.9.0 users... Fortunately, its install.rdf file is compatible with St52, so it doesn't require any modification to install the theme there... But: I don't have XP here to check, so I have no clue how the theme behaves (if and at what degree it works) under an XP installation of Serpent 52.9.0... All I can tell you is that when I first installed it in my Vista SP2 installation of St52, the tab bar was BROKEN/mostly unusable; I had to unpack the theme and apply trial-and-error many times, adding several additional "(-moz-os-version: windows-vista)" conditionals to select script places, to get a properly working tab bar on Vista, keeping full Aero support, too... Along with the theme itself, I'm also using the "Classic Theme Restorer v1.7.8.2019.10.27" extension (by Aris), to further modify it to my liking... A glimpse of what it looks like as I type this is: I understand Photonic (being an abandonware for Basilisk, at least for now) is susceptible to future partial/complete breakage, as Serpent 52 is being further developed - though, TBH, I don't expect "deal-breakers", as "upstream" very infrequently touch the GUI code; some minor bugs did fall under my radar, but I'm willing to live with them for the time being... So, now you know!

With respect, the way I understood his query was that he wasn't disputing whether package files whitelisted by ALL VT engines exist, but how many of them in total... It would appear the two of us interpreted somewhat differently @Dave-H's query, but only he can clarify that further ; all's well, BTW . It's the same web extension (but in .CRX format) I had advised installing in all three 360EE variants, which lack a native spell-checking feature . Thanks for your kind words you two , but I'm not worthy of more praise than any of the rest of the MSFN members/volunteers, who offer help to others out of their spare time (I'm actually typing this being on vacation) and without charging a (euro)cent for it! I find I can't be omnipresent in all the various places of MSFN, so, Mozilla-based browsers being a field of expertise, I tend to offer help there (and now I should probably stop derailing this thread any further ... ) ! tschüß

... Right ! Like you, I need to put my (presbyopia) glasses on... I now see (glasses on) that the VT test refers to "ProxyPopMenu.bat" file... He in fact wrote: Which browser is used to post these? Installing an en-US/en-GB dictionary in the browser and enabling spell-checking will flag misspelled English words as you type them, before you make the post public (i.e. submit it); that way, you can still improve your English along the way, but keep your posts (mostly) error-free ! E.g. in St52, if I misspell its past tense, "misspelled", it would appear as below: That way, I'm alerted I typed something wrong and then try to correct it!

Hmmm... The picture only shows that all which AV engines whitelisted the complete package file "ProxyPopMenu.bat", NOT which files inside the complete package were found to be benign, which, I believe, was what was actually queried by @Dave-H ... ... English lesson of the day! Should've been: "Batch files themselves" (if you were going to use the plural number ) ... Thanks for your efforts, BTW!

This behaviour is controlled by a Google SSUAO; latest Serpent 52.9.0 has it as: general.useragent.override.google.com;Mozilla/5.0 (%OS_SLICE% rv:71.0) Gecko/20100101 Firefox/71.0 Basilisk/52.9.0 i.e. it spoofs itself as Fx 71.0; result: (that one above is with its dark theme enabled - selection is stored inside a cookie ) If you're in the habit of using localised Google TLDs (e.g. google.co.uk) other than ".com", you need create additional SSUAOs for these...

Most unfortunately, @martok isn't willing to "fix" Bank sites in UXP-based browsers through his extension : https://github.com/martok/palefill/issues/38#issuecomment-1192738141 The reasons he cites are security-related ...

Welcome to the MSFN forums! As a general rule, consulting your browser's Web Console/Browser Console/Error Console will provide useful hints/clues as to the "why" : ... and even if that's "Greek" to you, it'll give prospective helpers a general idea... The ING Bank site relies heavily on customElements, a web spec (part of the Web Components JS+CSS framework) discussed, by pure coincidence , in posts of this thread's previous page... CE/WC is a technology originally created by Google (they currently are the only ones who dictate how the web should evolve ), the upstream developers of UXP/Pale Moon, due in part to their aversion of anything Google, put WC support inside UXP in the "back-burner", so to speak; truth be told, there still exist major technical issues to backport/glue-in all of WC to the platform, which, as you might already know, evolved from a now quite "old" Mozilla Firefox forkpoint... CE/WC are currently behind a disabled pref, in an incomplete/immature developmental state... Third party extension authors try. with various success and targeting selected URLs only, to mitigate lack of CE/WC support in UXP-based browsers ; at this point in time, the extension which holds the best promise for UXP users is one maintained by your compatriot Sebastian Hütter, aka martok, which is called palefill: https://github.com/martok/palefill/releases Install the XPI file linked in that page and then kindly ask him to include support for ING Bank, by filing an issue (GitHub account required): https://github.com/martok/palefill/issues From my initial testing, implementing support would be as easy as adding in file "./lib/builtin-rules.js" below code: exports = String.raw` +www.ing.de + std-customElements +! -- developer.apple.com std-customElements For your convenience, I have prepared myself a patched XPI file of palefill, (.XPI file attachment removed on 202208160022Z) that you are free to test; works as intended here (under latest St52): Later addition: Bank sites are a major pain in the posterior for "legacy"/non-mainstream web engines, because Bank IT staff insist on using the very latest Web Specs in them (even ones that haven't yet made it to final state, though this is not the case for CE/WC), as they think it gives the higher members of the Bank's hierarchy (who probably know little about web development), as well as most of the Bank's clientele, a false sense of "on-line security" ... I'm not saying Bank sites should stick to TLS 1.0/1.1 to merely satisfy old browsers, but not always using the latest Google-derived "shinies" won't make their sites (and their customers' interactions) less secure, would it?

This is a known and long-standing issue for both UXP-based browsers (such as Serpent 52.9.0), as well as the test Serpent 55.0.0/moebius builds... https://repo.palemoon.org/MoonchildProductions/UXP/issues/1344 (Part of https://repo.palemoon.org/MoonchildProductions/UXP/issues/1361 ) ... Turns out I had already toggled "dom.enable_performance_observer" in Serpent 52.9.0, too, without even realising ; so it appears that the default setting in UXP-based browsers as well as in St55 is to have "PerformanceObserver()" disabled, for whatever reason...

Finally, I did find some time (actually, a quite big chunk of time ) to troubleshoot the "about:support" instant crash in recent NM27 builds... The last build (buildID=20220722014511) without the crash (LastGOOD) was from package: palemoon-27.10.0.win32-git-20220723-b6b16147cc-xpmod.7z while the first build (buildID=20220729155323) exhibiting the crash (FirstBAD) was from package: palemoon-27.10.0.win32-git-20220730-93f97225b6-xpmod.7z More recent NM27 releases still crash here when "about:support" is being loaded... In my dirty NM27 profile, the OS crash report is as below: Problem signature: Problem Event Name: BEX Application Name: palemoon.exe Application Version: 27.10.0.7727 Application Timestamp: 62e4040f Fault Module Name: StackHash_a950 Fault Module Version: 0.0.0.0 Fault Module Timestamp: 00000000 Exception Offset: 00000000 Exception Code: c0000005 Exception Data: 00000008 OS Version: 6.0.6003.2.2.0.768.3 Locale ID: 1032 Additional Information 1: a950 Additional Information 2: c07297ba8acc6462e9fe86ee369f49b9 Additional Information 3: 0a9c Additional Information 4: 524d1a1d9730c6e8f6d176ea5e0fcd20 In a new, fresh, NM27 profile, "about:support" loads OK as expected... In safe mode, my dirty profile ALSO CRASHES, which means the crash isn't (probably) being caused by an extension, but rather because of one (or more) of my user-modified "about:config" prefs (file "prefs.js" inside my NM27 profile). That file is quite big in my case; many entries are originating from extension settings, so these could be disregarded (because the crash happens even in safe mode), but that still left me with a large number of candidate culprits... To cut a long story short, after a lengthy trial-and-error procedure, I managed to isolate the culprit pref: webgl.force-enabled;true It was a remnant from some time ago (probably more than a year), as a result of me force-enabling WebGL in older builds of NM27 in this laptop... That way, I could get in "about:support" => Graphics: WebGL Renderer: Google Inc. -- ANGLE (Mobile Intel(R) 965 Express Chipset Family Direct3D9Ex vs_3_0 ps_3_0) Now that I had discovered the culprit pref, I toggled it to "false" (the default), but in doing so I discovered two additional bits: 1. In the LastGOOD build (see above), that pref has no bearing at all, because even in its default state of "false", WebGL Renderer was set to ANGLE (no force-enabling is required); as noted, "about:support" loads fine... 2. In the FirstBAD build (see above), and all builds released after it, WebGL Renderer now shows as "Blocked for your graphics driver version": Force-enabling WebGL in the "BAD" builds (requires a browser restart) will cause the "about:support" internal page to crash the whole browser - I see this as a regression/bug... The source-code changelog between "LastGOOD" and "FirstBAD" builds is: https://github.com/roytam1/palemoon27/compare/b6b1614...93f9722 The only one WebGL-related change is - Bug 1191042 - Use CreateOffscreen for WebGL instead of CreateHeadless. - r=jrmuizel (f98fd02e59) which altered source files: dom/canvas/WebGLContext.cpp dom/canvas/WebGLContext.h dom/canvas/WebGLContextState.cpp dom/canvas/WebGLContextUtils.cpp (plus some test files...) @roytam1 : Any insight from your part? This old (Toshiba) laptop has a vendor-modified, proprietary, gfx driver, I had already updated to the last the vendor released for this laptop model ...

Not seeing this one here: Actually, the feature (first implemented in Firefox Quantum 57) is currently in Moebius behind a pref, disabled by default: "dom.enable_performance_observer;false" I can't recall now why then upstream - MCP - had it disabled , but you can of course toggle it to true and get the same results as St52 on that GitHub test page... More info here

I would have worded it myself:

I made an error previously regarding Ch49 Google Store extension support, this is the now corrected part: The way I meant it was: Imagine a fresh installation of either Windows XP SP3 or Vista SP2; while the installer of Google Chrome 49.0 is still recoverable, building a fresh profile of it with a set of many useful (and usable) extensions is currently very difficult, if the "Store" is the only source of extensions (and, as I recall, Chrome 49 will not permanently install unsigned extensions from other repos) ... This is what I have been constantly doing since the start of this year, making an archive of all indispensable Chrome extensions to be used alongside any of the three 360EE variants; MV3 requires at least Chrome 88 by definition, most sadly there hasn't been (yet?) produced a Chrome 88+ fork that would run under Vista SP2/XP SP3 (NB: I'm talking here about 32-bit OSes) ... ... And if you disable ChromeFill and restart browser, you'll find more "REDs" (belonging to APIs you have polyfilled in the extension)...

Without me sounding pessimistic, any effort in 2022 targeting Chrome 49, for the benefit of XP/Vista users, is a futile one... Chrome 49 is extremely outdated by today's WebCompat standards, not to mention security-wise (has more holes than Swiss cheese... ). It's practically unsupported by Google Store, as it only supports up to CRX2 + MV2 extensions, when most CRX2 ones have already been removed from the store (updates only come as CRX3-packaged) and MV2 ones are being phased out en mass in 2022 (and would be fully deprecated in 2023); not to mention the fact current/active extension authors only target the most recent versions of Chrome; I keep a copy of it myself, and I can tell you it's a "dead man walking"... Under XP, you'd definitely need to couple it with a TLS 1.2/1.3 "secure proxy" to access most of today's sites, but page rendering will be dire... If you intend to bridge all the missing Web APIs introduced after Ch49 (to, say, Chrome 70 level) via polyfills, that would be a pharaonic task, if at all feasible... But be my guest, of course... With just GitHub in mind, they provide a utility/wizard with which one can inspect all MISSING Web APIs in the client (browser) for it to fully support their latest GitHub incarnation: https://github.github.com/browser-support/ Currently, latest St52 has as missing (in RED) only "customElements" and "RegExp Named Capture Groups", so support for those has to be implemented via an extension (i.e. palefill); I fear that wizard, if at all rendered properly in Chrome 49, would have many RED entries... Using the wizard with declining Chrome versions (starting at v69 and going down by one major version), you can test which minimum version is currently supported by the extension as-is and then decide how "low" in the Chrome versions you want/is feasible to extend support to (on the availability of polyfills for the missing APIs as you go down the range...).

ChromeFill isn't intended for such an old a Chromium version, unfortunately... BTW, and this has been discussed quite a few times in the MSFN forums, be it in the past, Advanced Chrome wasn't in reality based on Chrome 54; much of it is in essence Chromium 48 based, with only traces of code borrowed from Ch49/52/54... @InterLinked should have been more verbose in his README.md and/or enforce a minimum Chrome version in his extension's manifest.json, so as not to create false expectations... I haven't tested fully all the range of Chrome versions in which the extension successfully restores GitHub and other supported sites, but as an educated guess I'd claim that anything under Chrome 68(-ish) is currently unsupported... As I stated already, ChromeFill for XP/Vista users currently only targets 360EEv11/12...

Since you have posted in this very thread, be informed it is mostly frequented by Windows XP die-hards, plus a few (like myself) Vista "bastions" ; H/W is fully relevant here, because those under old, under-resourced, H/W will prefer those two 360EE versions I cited, as being more "gentle" towards system resources... Those with more "juice" can opt for 360EEv13/13.5 (Ch86-based) and/or MiniBrowser (Ch87-based); BTW, as I'm sure you do know already, Iron 70 (Ch70-based) with the "non-screwed" Chromium GUI requires at minimum Win7 SP1...

For GitHub exclusively, you may want to have a look at https://github.com/martok/palefill/issues/29#issuecomment-1186046465 and https://github.com/dirkf/palefill/commits/df-optchain-patch https://github.com/dirkf/palefill/releases/tag/v1.19df The dev(s) use simple transpiling JS code for just those two operators, nothing more (the rest can be handled by polyfills, like already done in your extension). You might have to ask kindly though , because the dev(s) are primarily concerned with SM 2.53.12 and/or PM < 31 support... Target groups for a "fixed" GitHub via your extension, ChromeFill, would be most XP+Vista users on low-end H/W, currently using 360EEv11 (Ch69-based) and/or 360EEv12 (Ch78-based) ... I would have been quite taken aback, had they actually done something ... GitHub's fate is under Microsoft's rule for years now, they're currently focused on their latest crapware/adware Windows 11 OS, together with their illicit lovechild, Microsoft Edge (the "fruit" of them having intercourse with Google ...); I'm confident they don't give a rat's a** about Net Neutrality or have any iota of intention to support those marginal "few" still on browser-engines not compatible with the evil operators (already implemented in Chrome 80...); BTW, I did "upvote" your - currently still "unanswered" - GH community issue; 3 weeks have now gone by, it's quite telling that no official GH dev will act on it...

@AstroSkipper : Most fortunately, Feodor2 has now implemented support for both (?.)+(??) in Mypal68: https://github.com/Feodor2/Mypal68/commit/43621d4ff863a03e80b39056ca360a992c2adb16 https://github.com/Feodor2/Mypal68/commit/2c4b98e1644707f29bbc6849e89d352e87ca1ef6 so #60 and, by consequence, #109 are now closed! Latest Mypal 68.12.5b should be able to handle GitHub correctly now... So, UXP-based browsers+palefill, 360EEv13[.5], Minibrowser87 and Mypal 68.12.5b are a set of browsers that can handle GH under XP/Vista ...

Right : https://github.com/janekptacijarabaci/greasemonkey/commit/60ded5b304d2fb616e61137e9209bb7993b55a9b Please, don't take it as a personal offence, as it was not meant that way... If you're an extension author yourself/quite savvy with browser code and the Javascript language, then I'm quite confident you'll find ways of getting out of whatever "predicament" you find yourself into by not "playing by the rules"... However, the layman user of Serpent 52 (under XP/Vista or, even, 7) will be much better off by doing "things" the recommended way; then it'd be more easy for a volunteer helper (like myself) to troubleshoot reported breakages and offer remedies, if/when possible... I am also of an adventurous "nature", but this trait has sometimes necessitated a complete browser profile rebuilt from scratch, which, depending on the original profile, can last from many hours to even day(s) ; I'd never myself promote "behaviour" that would end up in someone having to rebuild one's browser profile... In the past, I was a Mozilla Nightly Tester (v22.0a1 to v53.0a1), Firefox Nightly was being released then once a day (currently twice daily), profile "breakages" were quite frequent between updates, so one was never to mix profiles even between Firefox Nightly versions... While indeed Basilisk 52 (and, thus, Serpent 52) began its existence as an offspring of Mozilla Firefox 52.6.0 (this is an over-simplification; UXP-take 2 - the platform - began its life as a fork of Mozilla ESR 52.6.0 platform), the close affinity between them might have been a "thing" in early 2019, possibly for somewhat longer, but due to extensive work by upstream (MCP), the two platforms/applications have, by now, diverged so greatly, that their profiles are no longer interchangeable! My 2c/2p (etc.): Never mix profiles between browsers (obviously when they belong to the same "family"), or between different versions of the same browser (and Google/Mozilla have made it now impossible to successfully "downgrade" profiles, as profile migration is only ONE-WAY exclusive: from an older to a newer browser version). UXP-based browsers (and forks) have kept support for old and unmaintained Firefox "legacy" extensions; where the UXP community has created UXP-specific versions of those, it is wise to move on to such an extension fork... E.g., Stylem should be used as the de facto UserStyle manager over the Firefox-specific, old, Stylish v2.0.7/2.1.1... Kindest regards

To all other members reading this, PLEASE NEVER DO THAT! Not playing by the "rules" makes you ineligible for help, at least as far as I'm concerned... Nothing to be wary of GMFPM - its maintainer is/was a member of the MCP team of devs... I've been using it for years without the slightest issue... What is, in this case? I provided detailed, foolproof, instructions for the migration of GM 3.17 => GMFPM 3.31.4 (which is fully compatible with UXP browsers), but you're unwilling to even test it (you can always use a test St52 profile) ... BTW, people still using FxESR52 in 2022, except for some marginal cases like Firefox Sync, should migrate ASAP to St52, not only for security reasons, but mainly for WebCompat ones... Nothing too complicated for a die-hard Windows XP(/Vista) user, trust me...

As I've written countless times in the past, Serpent 52.9.0 != Firefox 52.9.x As such, you should NEVER mix profiles between FxESR52 and St52/St55! For UXP-based browsers (like St52), the UserScript Manager of choice is: Greasemonkey for Pale Moon Despite its name, it's also suitable for Serpent 52/55; first 1. Uninstall your very old GM (for Fx) v3.17 (its settings should be kept inside "about:config", already installed scripts should remain intact inside your St52 profile) - restart browser. 2. Install file "greasemonkey-3.31.4-pm_forkBranch.xpi" - restart browser. 3. Installed userscripts and GM settings should have been carried over to GMFPM-3.31.4 Another option for St52 if you only wish to modify web content is ViolentMonkey (a web-extension, NOT backwards-compatible with GM); latest v2.13.0.23b works fine in my copy of St52...

Package filename: palemoon-27.10.0.win32-git-20220730-93f97225b6-xpmod.7z New Moon 27 Version: 27.10.0 (32-bit) (2022-07-29) BuildID=20220729155323 The whole application crashes when loading "about:support": In my case, I had "Troubleshooting Information" as a pinned tab and Session Restore enabled, thus the browser was crashing as soon as the session was being restored ... Took me a while to figure out what was going on... The "Inspect Element" bug doesn't seem to be fully rectified - while the Inspector (DevTools) might eventually open (after causing the browser to "freeze" for some secs), its behaviour depends on the page inspected - an MSFN test page worked OK, but a GitHub test page soon provoked the infamous appcrash... Whatever upstream are doing with Developer Tools, they're starting to break my favourite NM27 dark theme (FT DeepDark 9.5.4); not their fault, I know, since that complete theme was targeting originally Firefox 27 - and even had to be modified slightly to accommodate official Pale Moon 27.9.4 - but just saying this as an observation ...

@roytam1 : https://forum.palemoon.org/viewtopic.php?f=61&t=28657