Jump to content

VistaLover

Member
  • Posts

    2,328
  • Joined

  • Last visited

  • Days Won

    101
  • Donations

    0.00 USD 
  • Country

    Greece

Everything posted by VistaLover

  1. ... I beg to differ : then:
  2. Since last May 3rd, GitHub's layout is rendered considerably BROKEN under UXP-based browsers, but, at the same time, remains 95% usable... The breakage in the layout is caused by UXP not supporting max()/min() CSS functions, first implemented in Fx75: https://developer.mozilla.org/en-US/docs/Web/CSS/max https://developer.mozilla.org/en-US/docs/Web/CSS/min This is being tracked by upstream in #2230 (read PM Forum entry here); since Mozilla implemented that in Stylo, it's a Herculean task to backport this to UXP, hence that issue hasn't seen any activity whatsoever over the last 5 1/2 months ... Until June 16th, it was still possible to revert to the old layout, that rendered OK in UXP, by blocking several so-called "primer-primitives" GitHub CSS files, but that trick stopped working past the aforementioned date ... To add insult to injury, Microsoft today shoved down GitHub users' throats another layout abomination in the shape of the "Global Navigation Update", which was, until today, just a "Feature Preview" one was able to toggle off... People are, of course, just hugely dissatisfied, e.g. https://github.com/orgs/community/discussions/52083#discussioncomment-7297619 https://github.com/orgs/community/discussions/52083#discussioncomment-7297646 https://github.com/orgs/community/discussions/58295 but, as ever, big companies like MS will simply force their own "vision of progress" ... Here's an archived screengrab taken on 2023/05/01: whereas below is the same GH URI as it renders now in St52: The red rectangle highlights the broken area in the new GitHub "header" ; this, I found, can be mitigated for now by blocking another set of "primer-primitives" GitHub CSS files, and I did that via a custom filter inside uBO-legacy: ||github.githubassets.com/assets/primer-primitives-$stylesheet,domain=github.com,important Result: Of course, the new layout abomination also broke several custom userstyles/userscripts I have installed for GitHub that target its header, thus exacerbating my overall frustration over this unwarranted change (for the worse) ; it's final : "desktop" web page design has ceased to exist; convert everything to a mobile-friendly layout, with ceaseless page scrolling added on top as cake frosting (Google Search did exactly that some weeks ago, abolishing search result pagination) ...
  3. ... Yes, it appears dbsoft (aka Brian Smith), the leading MacOS upstream developer , is (occasionally?) monitoring this thread : https://repo.palemoon.org/MoonchildProductions/UXP/issues/1442#issuecomment-38212 Even Moonchild himself got involved ; however, as I stated in my original post, MCP's Stream API implementation is still in an "embryonic" state (FxESR 68 levels) and, despite the linked "partial fix", vk.com video clips will remain mostly incompatible: TL;DR: Even when that "partial fix" lands on our UXP forks, @Mehmed will have to keep the Streams API disabled, if he's a frequent user of VK ...
  4. ... You assumed wrong! I have practically run out of breath in these threads saying that just because St55 has an appVersion (55) greater than St52's (52), that doesn't imply at all "it's slightly newer and better"... St55 is a "relic" browser application, initially seeing the light of day as a fork of upstream Basilisk test browser application, built on UXP Take 1 platform (aka moebius); moebius was mainly based on a Mozilla Nightly 53.0a1 platform snapshot (which, to this day, no-one among "us", even roytam1, is able to trace exactly ), with bits of Mozilla 54 and 55 squeezed in; appVersion 55 was chosen for purely "sensationalistic" reasons... When upstream killed moebius in favour of UXP Take 2 (i.e. current UXP), roytam1 kept that tree and occasionally (monthly) updated it with code from other repos, like Mozilla itself, TenFourFox, IceWeasel53 and UXP; during one of the CoVid19 lockdowns in Hong Kong, roytam1 found the (huge) amount of time needed to realise the task of bringing his St55, engine-wise, "closer" to his UXP-based browsers, i.e. St52 and NM28; let me assure you that, by that time, UXP had progressed so far from its initial fork point of Mozilla ESR 52.6.0, that St55 was lagging way behind it... After that task was (mostly) completed, St55 tries to keep up with upstream UXP and St52, hence weekly updates for it are back, but even now St55 isn't 100% on par with St52, feature-wise ... If you ask me, the two reasons to prefer St55 over St52 are: 1. You're using (the otherwise unsupported) forced multiprocess mode in the browser, since, by inheritance from Fx-53.0a1, St55 has slightly better e10s support compared to St52 (which it inherited from Fx52 - upstream have, by now, eradicated all traces of e10s from their "official" UXP tree). 2. You have a need to use some WebExtensions which target/work with Fx53+, but don't with Fx52 - WE support, as inherited from Fx-53.0a1, is "slightly" better to the one currently extant in St52 - again, MCP have, by now, eradicated all traces of WE support from their "official" UXP tree... In the future, when people in these threads report issues with "Serpent", they should definitely "clarify" which one they're talking about ... As you might have guessed by now , my reason for arriving at #1361475 was solely the generated error inside the log @j7n had posted previously; you (and I) assumed he was using the UXP-based St52 and the "upstream fix" (from 2019) you linked to is relevant just for UXP; has this "fix" been ported over to your Basilisk55 tree already/is it present since the moebius very beginning? If not, I'm still right pointing the finger at Bugzilla #1361475 for generating: Respectful regards ...
  5. Hi @nicolaasjan , hope you're doing great and that the Dutch weather hasn't turned very cold yet ... In yt-dlp/commit/8a8b545 , PR #3668 was merged; this one adds an optional dependency to the requests python module, itself depending on the urllib3 python module; here's the latest yt-dlp requirements file: mutagen pycryptodomex websockets brotli; platform_python_implementation=='CPython' brotlicffi; platform_python_implementation!='CPython' certifi requests>=2.31.0,<3 urllib3>=1.26.17,<3 The "official" yt-dlp_x86.exe file has those already bundled, e.g.: [debug] yt-dlp version nightly@2023.10.15.085452 [4e38e2ae9] (win_x86_exe) [debug] Python 3.7.9 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 1.1.1g 21 Apr 2020) [debug] exe versions: none [debug] Optional libraries: Cryptodome-3.19.0, brotli-1.1.0, certifi-2023.07.22, mutagen-1.47.0, requests-2.31.0, sqlite3-3.31.1, urllib3-2.0.6, websockets-11.0.3 and so does the latest yt-dlp_x86.exe file you provided yourself (compiled via GitHub Actions): [debug] yt-dlp version nicolaasjan/yt-dlp@2023.10.14.034319 [8a8b54523] (win_x86_exe) [debug] Python 3.7.9 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 1.1.1g 21 Apr 2020) [debug] exe versions: none [debug] Optional libraries: Cryptodome-3.19.0, brotli-1.1.0, certifi-2023.07.22, mutagen-1.47.0, requests-2.31.0, sqlite3-3.31.1, urllib3-2.0.6, websockets-11.0.3 HOWEVER , the py3.8 based , [debug] yt-dlp version nightly@2023.10.14 [8a8b54523] (win_x86_exe) [debug] Python 3.8.13+ (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.1.0-dev ) [debug] exe versions: none [debug] Optional libraries: Cryptodome-3.19.0, brotli-1.1.0, certifi-2023.07.22, mutagen-1.47.0, sqlite3-3.35.5, websockets-11.0.3 and py3.9 based, [debug] yt-dlp version nightly@2023.10.14 [8a8b54523] (win_x86_exe) [debug] Python 3.9.13 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.1.0-dev ) [debug] exe versions: none [debug] Optional libraries: Cryptodome-3.19.0, brotli-1.1.0, certifi-2023.07.22, mutagen-1.47.0, sqlite3-3.37.2, websockets-11.0.3 latest offerings do NOT ; as the official 32-bit yt-dlp builds will soon move to py3.8 , I'll have to rely more on your own py3.8/py3.9 builds (at least until I set up myself an environment to produce mine ); is it technically possible to add requests+urllib3 to those builds of yours ? Kindest regards ...
  6. This is probably Bugzilla bug #1361475 ; Mozilla fixed it in Firefox 55.0a1: https://hg.mozilla.org/mozilla-central/rev/68543862570f https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/55#web_audio_api
  7. Indeed, https://www.radio-browser.info/topclick leads nowhere ; one might use: https://www.radio-browser.info/search?page=1&hidebroken=true&order=clickcount&reverse=true to get that info, though ...
  8. It loads without "an actual web server", if file "Lights.html" is drag-n-dropped on a Serpent 52 New Tab, provided you temporarily disable (from true to false) "security.fileuri.strict_origin_policy" pref:
  9. ... If I were asked , I'd definitely say that Panda artificially blocked their Panda Dome (i.e. Free Antivirus) setup from successfully initiating+completing installation under XP SP2 64-bit; if you download the latest off-line installer (via already provided links) and then open/extract file FREEAV.exe with 7-zip, then you'll find below directories: FREEAV.exe\System64\drivers\2003\ FREEAV.exe\System64\drivers\XP\ containing 64-bit application drivers for WS 2003 x64/XP x64; why put them there if the application isn't supposed to install under those OSes? The fact those 64-bit drivers exist inside the installer probably explains why forced installation on XP x64 works; as for the app itself after installation, I'll quote AstroSkipper: Regards
  10. ... Since we all know by now that you are a mathematician , some additional attention to detail should be exercised (because mathematics, like physics and chemistry, is an "exact" science); what I did post was: Notice the unit I used! https://tecadmin.net/difference-between-megabyte-megabit-and-mebibyte/ So, 93,181,864 B ≈ 88.86515 MiB ≈ 93.1819 MB It might be, in the end, that your Android tablet was correct , reporting a file size of ≈ 93 MB (if MB was taken at its exact, scientific, value) ; actually, I think Microsoft (and, possibly, other vendors) are mistakenly using MB instead of MiB; Windows Explorer is indeed calculating file sizes in binary prefixes, but it displays the units used in their decimal prefixes; MediaInfo, which can be used on all sorts of files, not just "media" ones, displays file sizes explicitly in MiB: Windows Explorer's Context Menu: MediaInfo (simple) Context Menu: Hope I helped ! Best regards.
  11. It's related to the newly implemented Fetch Stream API by upstream: https://repo.palemoon.org/MoonchildProductions/UXP/issues/1442 (details about the API itself: https://developer.mozilla.org/en-US/docs/Web/API/Streams_API ) Their code is still incomplete/bugged - those two prefs you mentioned simply turn that API off... FWIW, the same crash occurs on latest NM28 (32-bit) on the very same VK clips you referenced (later edit: @anton12 beat me on that ) ... As a side-note, since you're well known to run St52 in e10s mode (completely unsupported by upstream), the fix on St52 itself (with multiprocess force-enabled) might involve additional codepaths, too ...
  12. Dear Astro , we had the same discussion in the past, without any conclusive result ; the link you re-posted just now, http://acs.pandasoftware.com/Panda/FREEAV/193309/FREEAV.exe , is still valid, I just tried it mere seconds ago, but from my location it just fetches the exact same binary (sized 88.9 MiB, not 93) as the link I posted in my previous post, http://acs.pandasoftware.com/Panda/FREEAV/Promo_pd/FREEAV.exe , with the exact (dual, i.e. SHA1+SHA2) digital sig of 2023/09/17 ! In any case, "the more the better" , interested MSFN members can try both for themselves! Kindest regards ...
  13. One can always use the same direct fetch URI as the on-line installer does: http://acs.pandasoftware.com/Panda/FREEAV/Promo_pd/FREEAV.exe This will get you the latest version of the off-line installer (88.9 MiB), with a dual digital signature of Sep 17th, 2023...
  14. Astro is right : https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP ditto ...
  15. Something ignored so far by previous posts: 1. The screenshot posted by @j7n has a blank page rendered on the plain HTTP version of "archive.org": http://archive.org I can replicate here on my "dirty" St52 profile: But the screenshot posted by @AstroSkipper (in NM28) has the secure version of "archive.org": https://archive.org Indeed, that one loads as expected in my St52 (dirty) profile; @j7n, does it also load for you when you specifically request the HTTPS version of AO?
  16. Although that was a question of a more general nature (at least that was how I perceived it), read below: https://learn.microsoft.com/en-us/dotnet/framework/64-bit-apps#running-32-bit-vs-64-bit-applications-on-windows If the question was specific to .NFW4, then yes, you do need both architectures of it: https://learn.microsoft.com/en-us/dotnet/framework/64-bit-apps#compiler-support-for-creating-64-bit-applications https://learn.microsoft.com/en-us/dotnet/framework/64-bit-apps#determining-the-status-of-an-exe-file-or-dll-file Adding to what others have said, it really depends on the actual .NET framework version+architecture a said application was built against (OT: On Win Vista SP2+, 4.x versions are mutually exclusive and backwards compatible - upgrading, e.g., 4.5 to 4.6 will overwrite the 4.5 previous installation)...
  17. As I've told you in the recent past , I only use a fresh browser profile when troubleshooting browser issues, otherwise I'm normally found on my working "dirty" profile (as is, I should hope, the vast majority of Serpent 52/55 users ) ; but just to humour you , a pristine/newly created St55 profile has no problem here loading quasi-instantly your referenced website: My "dirty" St52 profile as well as latest NM28 (minimal profile with just uBO-legacy installed) ALL load that website just fine! If you hadn't added the fact 360EEv13.5 works OK for you, I would have suspected some sort of IP pool ban, but now I'm all out of ideas... TL;DR: I can't reproduce myself, sorry...
  18. ... Must be something at your end : BTW, if you're forcing HTTPS (via an extension?), then please don't; the site is available ONLY over plain HTTP ...
  19. @AstroSkipper : https://www.wisecleaner.com/wise-anti-malware-review.html ... Both entries from 3 1/2 years ago ... The first question was never officially replied to , second review (from June 2020) is consistent with your own findings now ... TL;DR: Forget about it (just my 2c... ) ! Best regards !
  20. @roytam1 : Hi, hope you're doing well ... Very recently, Basilisk-Dev committed some clean-up code with regards to the unused Mozilla Crash Reporter feature and, additionally, to Mozilla telemetry, iOS and android unused remnants; basically, look inside: https://repo.palemoon.org/Basilisk-Dev/Basilisk/compare/6e626eb9e...d2d6c6c79 Do you think those ones that are applicable to "our own" Serpent 52.9.0 can be included in this weekend's St52 imminent release? Thanks for your hard efforts!
  21. ... Yes, I perfectly understood that in the first place , you were crystal clear, but I used your "statement" as a basis for my follow-up question(s), "no more, no less" ; couldn't imagine that, in itself, would be a "potential problem", is it? (FWIW, I get the overall sense one should "walk on eggshells" when replying in this thread ...) Thanks for the confirmation! Thanks, too, that is very comforting to know ... How does this fact make the MBAM online support articles I linked to look then? Thanks Dave for your detailed reply! ; hopefully, by the time you'll be up for the next renewal, you'll face no problem "re-activating" MBAM v3.5.1 on your two (thought it was just one ) XP partitions! Cheers.
  22. ... Such a "lifetime" licence, IIUC, was a "thing of the past" and no-longer available from the vendor, am I right? IOW, the average XP/Vista user has to either be content with the "free" version (on-demand scans, no RTP) or "cough up" a yearly premium subscription to get RTP... Speaking of an MBAM "premium" licence, might I be somewhat indiscreet and ask @Dave-H whether he's currently on an annual subscription plan in his XP partition? More importantly, can someone (on XP/Vista) today order and buy an MBAM v3 valid premium licence? Their on-line documentation speaks otherwise: https://support.malwarebytes.com/hc/en-us/articles/6003466611475 where "End of Sale" is defined below: https://support.malwarebytes.com/hc/en-us/articles/360039022993 Thanks for any insight!
  23. ... Well, whaddayaknow? A page in 2023 still employing Adobe Flash Player (viewed in St52): ... "Downside" is the suggested app is a payware, with only a 14d trial period offered (in contrast to previous apps mentioned, all freeware ; and no, I have nothing against "payware", coders do still need to make ends meet) ...
  24. ... Yes, I know - you were perfectly clear in the first place: a fresh/clean St52 profile isn't able to display correctly/permanently the embedded auf1.tv video player; my post (you replied to) was meant for St52 users wishing to view auf1.tv video-on-demand (VOD) content (probably inside Germany and the German speaking, neighbouring, countries); at least one extension is needed for that, in my case I made it possible with uBO-legacy and a custom filter (other ways exist, e.g. with uBO-legacy and custom allow/deny rules, as suggested by UCyborg, or with eMatrix and special settings, as suggested by Astroskipper); personally, I find it quite inconceivable for a normal St52 user in this day and age NOT to have a content blocker installed , so my advice was geared towards them! Hope I made it extra clear now ; warm greetings...
  25. ... However, if you have just uBlockO-legacy installed, in the My Filters tab just create the one below: ! 2023-09 auf1.tv ||auf1.radio/api/get$xmlhttprequest,domain=auf1.tv Then, the auf1.tv embedded video player will stay put in St52, too (otherwise, it starts to load, displays briefly and then moves out of sight , resulting in the image you attached in your "previous reply" ) :
×
×
  • Create New...