VistaLover

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

... Not only that, it appears it expects Fx 86.0 at a minimum, so close to zero chance it would've worked even if force-installed (via hacking its manifest.json file) ...

... I assume that was a stub/on-line installer, run on your Win8.1 setup, was it not? If that same installer is run under Win10+, it'll fetch the latest stable Chrome release, either v110.0.5481.177 or v111.0.5563.50 at this time... What will be fetched under Win7SP1 if that same installer is run? Probably just v109.0.5414.119/.120 (can't test right now) ... So, I guess, one has to first gain access to a Win8.1 box to grab the v109 security updates, to then install them under Win7SP1... Hopefully, the updated links will be made public to the Win7 communities, as they become available to 8.1/2012R2 users... BTW, one should better archive those v109 installers, because it's widely known Google will remove the builds from their servers , in due course, for being "insecure" ...

Can you please provide/explain the method you employed to obtain those links? How is one on Win7 supposed to get access to similar links until Oct 2023?

For St52/St55 users and AMO: Setting a SSUAO like below: general.useragent.override.addons.mozilla.org;Mozilla/5.0 (Windows NT 10.0; rv:110.0) Gecko/20100101 Firefox/110.0 will make all yellow banners and disclaimers go away; but, it appears AMO is now using the big blue "Add to Firefox" button ONLY for the latest version of an add-on, previous ones are only available via the "Download file" links: https://addons.mozilla.org/en-US/firefox/addon/decentraleyes/versions/ (you need to scroll down for the older versions)

@Mathwiz I couldn't have said it better myself, BTW ... If you're still interested in installing Decentraleyes for what it is/does, then its "legacy" version (v1.4.3) is found here: https://addons.basilisk-browser.org/addon/decentraleyes/ It installs out-of-the-box, and https://decentraleyes.org/test/ reports: FWIW, GitLab also has v1.4.2: https://git.synz.io/Synzvato/decentraleyes/-/tags/v1.4.2 in WE format, intended for FxESR 52, but I'd stick myself with the updated, "legacy", version 1.4.3... FTR, St55 comes with WE-support equal, or possibly slightly inferior, to Fx 53.0a1, so if a WE truly requires APIs to be found on 56.0a1+, it's expected it won't function in St55 (in any case, a bit of trial-and-error doesn't hurt when it comes to WE, because in some cases the minimum supported Fx version has been "artificially" increased by AMO ) ...

Possibly a cock-up by upstream? https://repo.palemoon.org/Basilisk-Dev/Basilisk/commit/dcb4e31c2c47f8daf7978e801aa632853d8ef922#diff-ef54fe37278363a5a6074fd58ec470b5683c06c3

... Actually, this isn't true... Yes, the yellow banner and other such disclaimers are there for me, too, but once you move to a selected extension's page, you'll be able (I hope ) to find a "Download file" link (directly to the addon's XPI file), e.g.: https://addons.mozilla.org/en-US/firefox/addon/decentraleyes/ =>

... It seems most evil Google have again patched this ; I now get: yt-dl -f 140-1 "p7FCgw_GlWc" => [youtube] p7FCgw_GlWc: Downloading webpage [youtube] Confirming age [youtube] p7FCgw_GlWc: Downloading API JSON [dashsegments] Total fragments: 1 [download] Destination: Kanye West - Famous-p7FCgw_GlWc.m4a [download] 7.7% of ~9.83MiB at 50.70KiB/s ETA 01:06 ERROR: Interrupted by user Terminate batch job (Y/N)? y ... Was fine earlier today, with a patched youtube-dl build of mine... yt-dlp is also affected now ... Had you been a fan of SNL's "Church Lady" in the mid-80s to 90s? Google are indeed "SATAN" (and are obviously keeping a keen eye on the yt-dlp/yt-dl repos) ...