VistaLover

IIUC, WiseVector StopX is/was a full-fledged Antivirus/Antimalware solution, with real-time (preventative) protection; OTOH, MWAV is a (portable) on-demand scanner, its purpose is: a) check whether your system is pristine/free of infection b) if infection has been found to have taken place prior to the scan, it offers solutions to get rid of it... Of course, since I haven't used either , the definitive answer will be coming from AstroSkipper ...

That's because these are ONLY offered when the videoID is an age-gated one && the tool is youtube-dl; with yt-dlp, as you wrote, the two audio variants, again for age-gated videoIDs, are labelled as "*" and "*-drc* (where drc = Dynamic Range Compression). TL;DR: When you're using youtube-dl and you stumble upon an age-gated videoID, if your script (for audio) specifically requests just "-f 140", then NO download for that ; you'd have to modify the audio format selection to be based on RegExp (and/or, perhaps, file extension of audio file) ...

... The "free of charge for home use only" download requires you "agree to send statistics related to the scanning process and your PC's software and hardware configuration to Doctor Web", else no free download ; more here ...

When you load "chrome://gpu/", under Graphics Feature Status, what are your entries for WebGL/WebGL2 ? I have a very old iGPU with only Software Acceleration available for both, so while the WebGL test passes OK, not every WebGL requiring site works as intended ... And in my case, force-enabling H/W acceleration ( "chrome://flags/#ignore-gpu-blocklist" => Enabled, followed by a browser restart) has adverse effects overall ...

... For me, the first map there (Wifi Triangulation) loads (both map/satellite view) if I enable the geolocation API (in St52: geo.enabled;true - I had it toggled to false, for privacy concerns ); but the second map (IP Address based on ISP) still displays the quoted error in satellite view, map view loads a lightblue colour:

OT ...Then, most probably, this one: https://www.youtube.com/watch?v=N2qqfafRdEQ /OT

I can confirm all the above with regards to (the modern GUI) VT site and latest St52 ; loading below link: https://www.virustotal.com/gui/file/9cd8677d185d0b8a23fe3a47eaca17332dd84ab76d6402485ecda60490da8459?nocache=1 results in an "empty" tab: ... however, the console error I get is more ominous than an unsupported web font: App did not load (Unsupported app) As mentioned by others, temporarily disabling WC allows the site (new GUI) to load/display/basically work, but at a heavy CPU tax: NB that in the above screenshot, ONLY the VT tab has been loaded, process "basilisk.exe" (not shown) is at a steady 51% CPU consumption here ...

FYI, original Bugzilla 658467 (Fx53) had to be followed by 1357656 (Fx54 - they had messed up fading with RTL labels, e.g. in Hebrew) and, later, 1363033 (Fx55 - cosmetic enhancement); I guess both should be considered for inclusion in Bk/St52, too...

OT ... Probably this: https://www.verywellmind.com/what-is-radical-acceptance-5120614 Podcast (plays in latest St52, it's NOT DRM'ed): /OT

Much appreciated, looking forward to it ! Thanks in advance ...

Just a heads up: Besides nullish coalescing assignment (??=), a known UXP "killer" currently, its "relative" logical AND assignment (&&=) has been let loose in the wild ; it, too, was first implemented in Fx 79 (Ch 85); what's worse, it triggers the very same console ERROR as (??=), i.e. : Error: expected expression, got '='

... But of course ; whatever you actually do for a living should always take precedence over anything else (including "volunteer" coding ...) ; my query was about such an implementation's feasibility, mainly ... ... Again, as I see it myself, caution should be exercised here, because New Moon [28] tabs (pre-Fx29 code/design) are different to Serpent tabs (being Australis); unless you were simply referring to just the code pertaining to the pref's creation ...

Thanks! I presume you did check "browser.tabs.fadeLabels" to be in its default state (true) ? This solidifies my theory, because NM28 (and PM32) a) doesn't use Australis tabs b) doesn't pose as Firefox, so TUP/TMP can't get "confused" about which of its internal code to apply on the app it's installed...

Hi ; your response here has been really appreciated by me (and, I suppose, by other members who happen to be Serpent 52 users); yes, that commit being the culprit was suggested by me from the very start ... Now, here comes "my" twist : Unlike the previous reporters who ALL use TMP (or one of its forks), I don't, so I haven't experienced any major breakage myself... I, personally, prefer tab-label-fading to ellipsis (...), has always been like that ever since Mozilla Firefox 53.0+ implemented it... FWIW, Serpent 55, another browser maintained by @roytam1, has this feature as a default one, since Serpent 55 is based on moebius (aka UXP Take 1), a platform initially forked (by MCP) from a Mozilla 53.0a1 snapshot... I'm running latest St52 (which, BTW, has all the WebComponents improvements merged-in, unlike latest Basilisk) and I do like the result : I'm not a coder myself, but I believe you implemented "Fade out tab label on overflow instead of ellipsis" on Basilisk after MCP did the same with Pale Moon; however, Pale Moon uses a pre-Australis default theme, while Basilisk (hence St52) uses the Australis default theme... Is your implementation directly copied from Mozilla or a backport of MCP's code? In any case, this new feature is now there, enabled by default, in latest NM28 - @AstroSkipper, does TMP/Tab Utilities Phoenix work as expected in latest NM28, or is it broken there, too? The implementation by MCP applicable on PM (witn non-Australis) is enabled (by default) via pref "browser.tabs.fadeLabels" (also discussed in passing by previous, affected, posters); however, the implementation in dcb4e31 doesn't include such an "opt-out" (and I can confirm no such boolean pref exists by default inside St52's about:config). Since this was initially a Firefox 53.0+ feature, I "presume" TMP and the like break now because they are programmed/configured NOT to expect it in an application advertising itself as Firefox 52.0; so, perhaps, the extension(s) can be modified/fixed to accommodate this new browser feature? You know how the saying goes: Extensions extend the browser, not vice-versa... Official Basilisk v52.9.2023.03.07 has been now released, with the "feature" backed-out... @basilisk-dev and, mainly, @roytam1: Can this new feature ("Fade out tab label on overflow instead of ellipsis"), instead of being summarily axed, be restored behind a pref (I don't care whether it'd be true/false by default) in Basilisk/Serpent for those, like me, who actually prefer it? If the new code interferes with TMP (and the way to go would be for that to get fixed - if it's actually still maintained ), then it could be simply pref'ed off/disabled... Thanks to all the coders involved for making it possible to still use, in 2023, browsers that look and feel "classic" but, at the same time, allow "us" to evade the Google Chrome browser monopoly (well, in most cases ) ... Kindest regards

This is a well known and already documented (at least by me , several times) current shortcoming of UXP, not related to WC/CE : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import Upstream have a currently "Open" issue about it in their UXP tracker: https://repo.palemoon.org/MoonchildProductions/UXP/issues/1691

... The embedded reddit post above mentions Pale Moon under Win7, but I can confirm Serpent 52 on Vista SP2 32-bit as having no issue whatsoever with the "reported" site (OT for this thread, I know, still ...).

... Just because things have gotten to be "how" they currently are "in IT world" doesn't mean I have to like or condone the way/speed with which they're "moving forward" (I use "forward" tentatively here; in many aspects, I feel it's just "progress" for the sake of "progress" itself ) ; so we have a new major version of Chrome/Firefox every 4 weeks; but why should web compatibility suffer so much, especially for those not willing to ride that high-speed train? Back in much saner times, there was a thing called "backwards compatibility" honoured among web developers; of course, the web itself then was a much nicer place, not the current JS-inundated abomination ... Rewind, please, to January 21st, 2010, when Mozilla Firefox 3.6 stable was released; no rapid-release-cycles at the time, the 3.6.x branch lasted all the way till March 13th, 2012, when 3.6.28 was released - some 26 months after the initial release; I was "there", and 95% of web pages would render in the same way between 3.6 and 3.6.28 ... FF to now and St52: You open a page today and it renders OK, revisit it next month, it may not load at all ... Nothing personal against you, UCyborg , I guess I simply needed to vent a little ...

... Can be found also inside ABBO: https://addons.basilisk-browser.org/addon/keyconfig/

... Unlike the "legacy" version of Stylish you're currently using, Stylus is exclusively offered in WebExtension format, thus not suitable for modifying the browser's GUI discussed here... FTR, the last version of Stylus compatible with St52 is the (now) old v1.4.23 (which was targeting Fx52+ back in the day...). I still use Stylus-v1.4.23 (together with Stylem-2.2.9) in my Serpent 52 profile, because Stylus (unlike Stylem ) does have support for the "*.user.css" format of userstyles, which is now the defacto format used in currently maintained userstyles (e.g. the ones published by StylishThemes); however, v1.4.23 is becoming quickly deprecated/unusable over the last year or so, because its CSS parser can't digest the Googlified CSS syntax present in recent, updated, versions of userstyles; newer versions of Stylus can, but they're not compatible with St52 ; so, one has to either a) implement full and proper support for "*.user.css" inside Stylem, b) backport a working/recent CSS parser into Stylus-v1.4.23 from newer Stylus versions, c) make a recent Stylus version compatible with St52; needless to say, I don't hold my breath for a, b or c to materialise ...

This is userstyle code, so you can either place it inside file: <browser-profile-directory>\chrome\userChrome.css (requires a browser restart to take effect) or use the userstyle manager Stylem to create a new userstyle containing the posted CSS code... FWIW, an "empty" userChrome.css file (aka userChrome-example.css) contains the below code: /* * Edit this file and copy it as userChrome.css into your * profile-directory/chrome/ */ /* * This file can be used to customize the look of Mozilla's user interface * You should consider using !important on rules which you want to * override default settings. */ /* * Do not remove the @namespace line -- it's required for correct functioning */ @namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); /* set default namespace to XUL */ /* * Some possible accessibility enhancements: */ /* * Make all the default font sizes 20 pt: * * * { * font-size: 20pt !important * } */ /* * Make menu items in particular 15 pt instead of the default size: * * menupopup > * { * font-size: 15pt !important * } */ /* * Give the Location (URL) Bar a fixed-width font * * #urlbar { * font-family: monospace !important; * } */ /* * Eliminate the throbber and its annoying movement: * * #throbber-box { * display: none !important; * } */ /* * For more examples see http://www.mozilla.org/unix/customizing.html */ Hope it helps

... For me (St52), the default is "false" :

Yes , because "??=" was first implemented in Chromium 85; 360EEv13.x are based on Ch86 and Kafan MiniBrowser on Ch87; but, I suppose, most members here already know this piece of info ; "we" are indeed lucky "we" still have the above forks in "our" arsenal , but, it's easy to realise, "our" luck under XP/Vista32 will run out when Google push out something working only on Chrome88+ ("we" already are hands-off from MV3 extensions ) ... Kind regards

... And there, they proudly state: which is something they definitely deserve a praise for! If only other "security" vendors had followed their example...

https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreadinformation

... Actually, the ball has always been on upstream's court, i.e. MCP... Roy basically makes sure nothing "they" have coded conflicts with his stupendous efforts to maintain XP/Vista compatibility in his UXP forks - of course, genuine platform improvements have been committed to his UXP tree (by backporting stuff from Mozilla and others), but if it's webcompat you're mainly interested in, you'd be in fear of disrespecting MCP, not roytam1 ... ... And that's exactly the crux of the issue: Due to Google's browser monopoly, ALL sites "that matter" are being tailored to work best on latest Chrome ... WebComponents+CustomElements have been fixed to work in the UXP builds released by Roy yesterday ; but sites/Google will always be several steps ahead UXP wrt Web Compatibility ; currently, several of "my" sites are broken due to "??=" (nullish coalescing assignment) ... Regards