Jump to content

VistaLover

Member
  • Posts

    2,381
  • Joined

  • Last visited

  • Days Won

    102
  • Donations

    0.00 USD 
  • Country

    Greece

Everything posted by VistaLover

  1. ... 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 ...).
  2. ... 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 ...
  3. ... Can be found also inside ABBO: https://addons.basilisk-browser.org/addon/keyconfig/
  4. ... 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 ...
  5. 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
  6. ... For me (St52), the default is "false" :
  7. 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
  8. ... And there, they proudly state: which is something they definitely deserve a praise for! If only other "security" vendors had followed their example...
  9. https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreadinformation
  10. ... 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
  11. ... 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) ...
  12. ... 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" ...
  13. 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?
  14. 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)
  15. @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 ) ...
  16. Possibly a cock-up by upstream? https://repo.palemoon.org/Basilisk-Dev/Basilisk/commit/dcb4e31c2c47f8daf7978e801aa632853d8ef922#diff-ef54fe37278363a5a6074fd58ec470b5683c06c3
  17. ... 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/ =>
  18. ... 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) ...
  19. ... "upstream" : youtube-dl (the original project); yt-dlp : "downstream" (the fork) ... For a fix from "upstream" , check this (and posted comments); WFM !
  20. ... But they didn't bother updating the copyright dates ... https://www.escanav.de/german/index-new.asp => Copyright © 2020 MicroWorld Technologies Inc. - Anti-Virus und Content Security https://www.escanav.de/german/content/products/MWAV/escan_mwav.asp => Copyright © 2021 MicroWorld Technologies GmbH - Unternehmenssicherheit They do support Vista/WS2008, so ; I'm rather curious, though, why Win8.1/10/11 aren't mentioned/supported?
  21. @joe92 Welcome to the MSFN forums ... It's the new UXP-killer "Googlism" I mentioned several pages back, the very reason all the discourse-based forums broke in UXP... The name of that "killer" is nullish coalescing assignment ... This operator was first implemented in Firefox 79 and Chromium 85; it's unknown if/when "upstream" can come up with an implementation in UXP, but what's certain by now is it's the "new" 2023 trend followed all the more by the well known "villain" sites (i.e. those that don't care in the slightest for "legacy" platforms and are eager to adopt the latest Google "shiny" ASAP ) ... BTW, "*.notion.site" and "*.notion.so" URLs are currently broken in UXP for that very same reason ...
  22. At least in Serpent 52, that behaviour depends upon the user setting in about:preferences#general => Downloads The default is: "Save files to: Downloads" and that generates the behaviour depicted in your screenshot... But when "Always ask me where to save files" has been selected (my preferred choice ), then when the browser is about to save a file inside a directory with a pre-existing file with an IDENTICAL filename, you are presented with a confirmation dialog where you're asked to confirm a file overwrite or, if you decline, you're back at the "Save As" window to type a new, custom/different, filename to save the new file under...
  23. ... Unless you have a recent GPU that supports H/W VP9 decoding, only S/W decoding via CPU takes place for 8k60 YT (do YT serve >=1080p files encoded in H.264?) - Wiki says that "full fixed-function VP9 8-bit and 10-bit decoding acceleration" was only added in Intel's Quick Sync Video v6, starting with Kaby Lake; don't know about the AMD side of things...
  24. ... This means they're targeting Win7 as minimum, now, either in their source code or the compiler they use is... In Vista, K32EnumProcessModules function is found inside psapi.dll, but in 7+ it was moved to kernel32.dll: see below: https://devblogs.microsoft.com/cppblog/windows-sdk-v7-0v7-0a-incompatibility-workaround/ If the actual source code is still compatible with NT6.0, then recompiling with defining _WIN32_WINNT=0x600 or PSAPI_VERSION=1 will produce a binary launching under Vista SP2 fine...
×
×
  • Create New...