Jump to content

VistaLover

Member
  • Posts

    2,109
  • Joined

  • Last visited

  • Days Won

    93
  • Donations

    0.00 USD 
  • Country

    Greece

Everything posted by VistaLover

  1. @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 ...
  2. 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...
  3. ... 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...
  4. ... 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...
  5. uBlock Origin (Web Extension) v1.47.3.1 (shown here) is actually: "uBlock0-1.47.3b1-git-20230224-gbb203d9" There's an XPI for that in the GitHub repo: https://github.com/gorhill/uBlock/releases/download/1.47.3b1/uBlock0_1.47.3b1.firefox.signed.xpi If one downloads the XPI on disk and then tries to install it in Mypal68, (I assume) it won't, because it requires Fx 79+, so I have no clue how it got there in the first place... Sometimes GitHub misbehaves and when you left-click the XPI link directly on the GitHub releases page, it'll bypass the "gecko" version check... Another hypothesis: Although functionally incompatible with a gecko68 engine, build "uBlock0-1.47.1b0-git-20230215-ge83dbd8" (while available as an XPI) would have no issues installing; perhaps that one progressively auto-updated through to 1.47.3b1 somehow? gorhill only changed the gecko version to 79, as far as auto-update was concerned, on Feb 19/20th ...
  6. ... to be embedded ; posting a simple HTTP link (clickable by the reader - but we know "how" this could go with members "here" ) should be OK: http://velosportsrehab.com/wp-content/uploads/2014/07/14190549632_3ecff46035_o-e1404331612790.jpg
  7. Yes, the UXP-based browsers (includes others besides NM28/St52), as well as St55/moebius (which gets features backported from UXP) ...
  8. ... Your secure link to the "spacer.png" image won't display properly, because the host (velosportsrehab.com) uses a self-signed+expired certificate: velosportsrehab.com uses an invalid security certificate. The certificate is not trusted because it is self-signed. The certificate expired on Tue, 5 July 2022 03:25. The current time is Mon, 20 Feb 2023 17:33. (Error code: SEC_ERROR_UNKNOWN_ISSUER) A plain HTTP link would be OK ...
  9. ... Hence my reference to Mypal68 users (a Fx68esr fork that can run under XP/Vista) ... ... gorhill started using Unicode property escapes : https://caniuse.com/mdn-javascript_builtins_regexp_property_escapes (First implemented in desktop Fx 78 / Chrome 64; FWIW, this feature was implemented in UXP only last Christmas, thanks to martok )
  10. ... Just fresh from the oven: Those among you here using MyPal68 with uBO (WE) as the main adblocker, it has just stopped supporting that browser choice... ; well, once again the "web on mobile" takes precedence over the "web on desktop/laptop" ; gorhill decided to bump the minimum Firefox requirement in his extension from v68 to v79, to cater to Firefox Mobile users on Android (Google here, again ... ) : https://old.reddit.com/r/uBlockOrigin/comments/111vv2y/ublock_origin_147_announcement_thread/j8pbwtc/?depth=2 https://github.com/uBlockOrigin/uBlock-issues/discussions/2497#discussioncomment-4997876
  11. If you do remember, several pages back, the "discourse forum platform" breakage under UXP, it is caused by "them" (or by a web framework "they" use) implementing "??=", the nullish coalescing assignment operator (they didn't have to , their forum platform used to work fine without it ); by pure chance it seems, that "google-ism" was first implemented in Chromium 85, only one major version before 86, the basis for 360EEv13.x ... Chrome stable is now on version 110, having abandoned Win7/8.1 support; do any of you reading this consider it "unthinkable" their web devs simply devise/create a "new" JS "shiny" that will be offered with some Chrome version >11x? Judging by what has happened already, they'll then forcibly bundle it with whatever Node/React/etc. web framework the "trendy/secure" sites "du jour" employ, breaking the web for those on Ch109 who resist an OS "upgrade" to Win10/11... I can't, at this time, answer precisely what the next "Googlism" is... I'm certain, though, it's already on Google's drawing boards - after all, if Google's dev teams don't break the web (and old clients) ever so often, they'll become redundant, won't they?
  12. ... Well, I couldn't reproduce with my Serpent 52.9.0 copy: ... i.e. I got the short-haired, young lady with spectacles ... And to avoid any chance of a possible misunderstanding, I'm not posting this to dismiss your claim, rather that for me, it was not the case ... Either it's a random thing or the algorithm they employ worked differently in my case vs yours ... Anyhow, I agree with you: "Variety" is the best thing, not sex-based stereotypes (oops , bait for OT posts here, apologies ) ...
  13. The second is true : However, I still get AstroSkipper's point; it's not actually needed (for now, perhaps in the future the auto-redirection won't work), but the posted link "could" be edited to reflect the current valid one (that doesn't trigger an auto-redirection in the background) ...
  14. ... Sadly, not the right screengrab linked (it's again the one for Vista SP2 x64+ExtKernel contained in your previous post ) ...
  15. ... All's good! However, looking back at all this, the "decision" of one member here to "shorten" (in order to "sanitise") a reference to a, otherwise popular , website has led to so many additional posts by other members here, including me, that only remotely (if at all) touch the subject of this thread ... Posts "exploded" to all aspects of human endeavour, i.e. natural sciences, history, linguistics, particular aspects of specific languages, education, Roman numerals, coins, ethics/morality, psychic health, addictions, human relationships/[pre-]sex, anything else I neglected? Even suggestions to not "avalanche" to further OT posts were disregarded, it appears... Each and every one of the above is a very interesting topic to converse about , however I humbly think here is not the most appropriate "place"; I, as much as anybody, can live with "a few" OT comments among a majority of posts with substance/relevance to the main subject(s) discussed in a dedicated thread; more than "a few" and I picture "trains de-railed" ... At the same time, some members here wonder why "these" threads reach so quickly the 200-page threshold ... (I'm also subscribed to these threads via e-mail notifications, "OT" posts also cram my inbox (and disk space, as I use a dedicated client, not webmail), so even more personal time needed to devote on sorting out the "valuable" from the "OT" e-mails...) Again, this is only my personal view on things, I don't expect all the rest to abide by it, but I'm entitled to it, aren't I? (NB: Don't do it; don't start another "OT avalanche" due to this post of mine; "reactions" (positive, only) are there for a reason.)
  16. ... Which was the exact point I raised earlier... AFAIAA, roytam1 has not (yet?) submitted any PR upstream, nor do I know whether he has any inclination to do so in the future ... And whether such an eventual PR relates to common code (between "our" UXP-fork and the "upstream" platform) or not, "upstream" do mandate that all issues & PRs submitted to their repo have been reproduced/tested on their "approved" application(s)... Some years ago, when MCP hosted their repos on GitHub, I had directly filed there a few issues discovered in NM28, with the note "I expect them to be 100% reproducible in PM, too"... All Moonchild had to do was try my STR in "his" browser; instead, I was frowned upon, my report disregarded, until I provide actual proof of the issue on PM itself ... I couldn't run PM in my OS of choice, so I then gave up ...
  17. ... While I am notoriously "famous" here for writing (and posting!) lengthy and detailed analyses, especially in the past, time constraints induced by RL (AstroSkipper: Real Life ) meant that often now I have to convey the info I want by referencing related link(s) - the info is there, just "not in my very own words" ...
  18. Actually, unrelated to what we've been discussing here... The multiple [1888] WARNING: file already exists but should not: C:\DOCUME~1\nico\LOCALS~1\Temp\_MEI18882\Cryptodome\* warnings are a manifestation of a very recent bug, which I have reported here (possibly related to the new "ways" PyCryptodome[x] is imported at yt-dlp's runtime and, thus, the "new" ways the module is being packed by PyInstaller) ... Even your very own compiles are being affected by that bug: https://github.com/nicolaasjan/yt-dlp/releases/download/2023.02.09.051430/yt-dlp_x86.exe https://github.com/nicolaasjan/yt-dlp/releases/download/2023.02.11.092312/yt-dlp_x86.exe (One needs Vista SP2+ [32 and/or 64-bit] to test these). The bug may be exclusive to the GitHub Actions compiled builds, because the ones I prepare myself locally (with CPython 3.7.16), as well as your "manual" build "yt-dlp_x86_Windows-XP.zip", do not exhibit this bug ... Sometimes I wish the yt-dlp devs left the code "at peace" for awhile, in a good-working-state... "Shouldn't fix what isn't broken" comes to mind... But what do I know (except for stumbling on bugs ) ?
  19. In that linked GH issue, you were at PyInstaller v4.10 (custom "yt-dlp" build); have you given their most-up-to-date version 5.3 (linked in my previous comment) a shot? The idea is that a custom build has a unique bootloader not shared with the rest of the EXEs compiled with the widely available PyPI edition of PyInstaller, thus raising less red flags (false detections) with (mostly) low-quality AV suites ... And, in any case, you did say in that comment that: So, you stand to lose nothing by trialing v5.3... My 2c, of course...
  20. Latest PyInstaller on PyPI is at version 5.7.0 ; yt-dlp "org" have used custom compiles of PyInstaller v 4.5.1->4.9->4.10->5.2 and are now (probably) using v5.3 ... The 32-bit wheels of those custom compiles can be seen in below branch: https://github.com/yt-dlp/Pyinstaller-Builds/tree/gh-pages/i686 Direct link for latest v5.3: https://github.com/yt-dlp/Pyinstaller-Builds/raw/gh-pages/i686/pyinstaller-5.3-py3-none-any.whl If you so wish, you yourself can switch over to this custom yt-dlp compile of PyInstaller: python -m pip uninstall pyinstaller (will uninstall v5.7.0 fetched from PyPI) python -m pip install "path-to-downloaded/pyinstaller-5.3-py3-none-any.whl" or even: python -m pip install "https://github.com/yt-dlp/Pyinstaller-Builds/raw/gh-pages/i686/pyinstaller-5.3-py3-none-any.whl" ... then build yt-dlp_x86.exe with that ...
  21. Thank you for this most excellent read ; lengthy, but still excellent! Considering it was written 7 years ago, I wonder what the author would've said about today's "abomination" of the web ...
  22. ... The UXP forks (NM28/St52) offered here by roytam1 (infinite thanks BTW ) are based 99.5% on the same application platform (UXP) that official Pale Moon (and Basilisk) is based on ... Like "our" forum, "theirs" is also inhabited by numerous very knowledgeable members; because the platform is more-or-less common, if issue "A" affects PM, there's a strong likelihood same issue "A" affects NM28 and/or St52... If solution to issue "A" is offered inside the PM forums, then good chances are the same solution will work for NM28/St52, too... Case in point, the recent "discourse" breakage... Fortunately, one can visit the official PM forums and read most content there without a mandatory registration - the site is safe, renders fine in "our" browsers and, frankly, is also a chest full of invaluable knowledge on "legacy" browsers, "legacy" extensions, etc. When I, @UCyborg or some other person here includes a link to the PM forum, should be assumed by the frequenters here that it links to content that is also relevant to "our" browsers , or, at the most extreme, it links to general discussions with tangence/interest to "us", too ... IOW, you don't have to use Pale Moon browser to follow a suggested link to their forum - FWIW, I don't use PM myself, for the simple reason it's incompatible with my OS, however that fact doesn't stop me from visiting their forum for "consultation" on various issues/problems (mind you, the forum is less "hostile" now to read, with "you-know-who" banned from posting ) ... I understand my opinion(s) might not resonate well with everybody here, "c'est la vie" , and, certainly, I don't want to sound unpleasant to some of you, but...
  23. ... Well , if only members here had been following more closely the recent exchange between UCyborg and me, and, more importantly, if link(s) to the official Pale Moon forum had been actually clicked on, then there would have been no room left for disambiguation of the abbreviation "PH" UCyborg used in his reply to me : ... thus: ... It appears (drawing from a past recollection of mine) that the "crowd" here is hesitant to click links pointing to MCP's forum, for whatever "deserved" or "undeserved" reasons ...
×
×
  • Create New...