Jump to content

VistaLover

Member
 View Profile  See their activity

  • Posts

    2,245

  • Joined

  • Last visited

  • Days Won

    93

  • Donations

    0.00 USD 

  • Country

    Greece

 Content Type 

Everything posted by VistaLover

  1. VistaLover
    ... And what exactly does this mean. even? In what way are browser extensions involved when one tries to access "chase.com" ?
  2. VistaLover
    ... It's because of what I hinted previously: Two ways to tackle this: 1. In "about:config", toggle "dom.abortController.enabled" to false, restart Serpent 52 and then installing the userscript from that GH page will work (just tested it now ); but the abort API is still needed by GitHub to properly function, so, after installing the userscript, reset the pref and, again, restart St52... 2. "Patch" the actual extension in below fashion: "./background/index.js" (a minified JS file): -!(!e.AbortSignal||!browser.windows) +(!!e.AbortSignal&&!browser.windows) Again, VM-2.14.0 works as expected in actual FxESR 52.9.x (it doesn't have itself the abort API), the breakage in St52 is due to MCP's (imperfect) abort API implementation inside UXP (FTR, VM's devs are almost oblivious to St52's existence ...).
  3. VistaLover
    ... Thanks, but over here, you're mostly preaching to an XP/Vista 32-bit congregation ... All the shinchiro compiled MPV (32-bit) builds target Win7SP1 as minimum OS requirement - you'll have to travel into the past to find the Vista EoS build, which was "mpv-0.32.0-157-git-20200223-g57ecfb4-i686_20200223" (from 37 months ago ); you'd have to travel way further back to find an XP-compatible MPV build (I don't remember off-hand, but the XP-users know it; from the 2015 era?) ... As for yt-dlp, Vista SP2 32-bit is still officially supported for a few more months (or until CPython 3.7 becomes EoL), however XP is not; thanks to co-member @nicolaasjan, XP-compatible yt-dlp builds (be-it third party) are being currently offered (just look at his MSFN signature ) ...
  4. VistaLover
    In Violentmonkey, I don't use myself: // @match *://*/* but rather: // @include *
  5. VistaLover
    ! However, as the people in the UK say: "The proof is in the pudding" , so I'll be waiting for next St52 builds (Sat 25/03/2023 ?) with bated breath (I'm a Southern-European close to the Mediterranean Sea, patience is not a true virtue of mine ) ...
  6. VistaLover
    ...Apologies... Forum's editor mishap ; step 5 in the STR should now have the correct links: Well, I had nothing to lose, so I did downgrade from VM-2.14.0 back to VM-2.13.2, as you suggested: Then, with "GitHub download ZIP" enabled, a simple visit to either one of the two (culprit) links will instantly provoke a full browser crash: ... and This is, again, with latest St52 ... FWIW, the crashes still appear whether you disable the native WC implementation/use the palefill extension for GitHub ...
  7. VistaLover
    ... Thanks for your immediate reply , especially that late on a Sunday night/Monday morning in your timezone ... I can't possibly start thinking where this finding leaves "me" here as far as Serpent 52.9.0 is concerned, because the STR "mix" involves a WebExtension (Violentmonkey), whereas "upstream" have eradicated (since years ago) WE support from UXP/Basilisk, so don't code/test with WE in mind; OTOH, existing WE support inside Serpent 52/55 has been practically left unmaintained (not because of any fault of yours , "we" understand its current status is: "Use at your own risk") at the level present when the platform(s) was forked from Mozilla... Unless there's something you yourself can code to "fix" this type of xul.dll crashes, I may have to look for "alternative" solutions ... Thanks, goodnight and have a good new (working ) week ...
  8. VistaLover
    Dear @roytam1 , I realise you're pressed for free time over this latest period, and I totally respect that, however ... ... I still get reliable/persistent/reproducible browser crashes in "xul.dll", as first reported previously here : ... even with the most-up-to-date Serpent 52.9.0 package ; STR: 1. Download and "install" package: basilisk52-g4.8.win32-git-20230318-3219d2d-uxp-85f6a4929-xpmod.7z 2. Launch a fresh St52 profile. 3. Visit: https://github.com/violentmonkey/violentmonkey/releases/tag/v2.14.0 and install file "violentmonkey-2.14.0.xpi" - FWIW, this is the EoS version for FxESR 52.9.x; the extension works as expected in Fx52+, but has some quirks in St52, due to MCP's faulty implementation of the abortController API (but this is material for another post ...). 4. Visit: https://github.com/Mottie/GitHub-userscripts/wiki/GitHub-download-zip and scroll to "Click this link to install from GitHub; or, install from GreasyFork or OpenUserJS." Proceed to install from, e.g., GitHub and make sure the userscript is ENABLED EDIT: To install the UserScript in VM-2.14.0, look here or here . 5. In a new browser tab, load either of: https://github.com/ytdl-org/youtube-dl/issues/32500 https://github.com/JustOff.atom Result: Instant crash: Problem signature: Problem Event Name: APPCRASH Application Name: basilisk.exe Application Version: 4.8.6.8298 Application Timestamp: 6411ec8e Fault Module Name: xul.dll Fault Module Version: 4.8.6.8298 Fault Module Timestamp: 6411ed8a Exception Code: c0000005 Exception Offset: 009c9623 OS Version: 6.0.6003.2.2.0.768.3 Locale ID: 1032 Additional Information 1: 508f Additional Information 2: 13f7db7a784678d3cc8ffd137f83d688 Additional Information 3: a4fa Additional Information 4: 7911363c0f1bdc89f23d695c08a2ab86 The browser doesn't crash if that userscript is being disabled while browsing GitHub (but my workflow demands I have it enabled ) ; also, the browser doesn't crash if I revert to the St52 build from a fortnight ago, i.e. package: basilisk52-g4.8.win32-git-20230304-3219d2d-uxp-33981efb4-xpmod.7z ... but that one is plagued by the "GH-timestamps-bug", so I'd rather not go back to it ... Can you reproduce? Does the "Problem signature" above provide any indication at all? This isn't a pressing thing for me, so you can deal with it as time permits, but it's very annoying here ; the two triggering GH URIs above are just samples, I may never know when St52 will crash on GH, with eventual data loss when it happens ... Thanks for your hard work and perseverance into keeping our aging H/W and/or OSes in a "working" state; your coding time plus all expenses/cost needed to maintain the compiling machine(s) and server(s) is being immeasurably appreciated by this community here (and elsewhere, probably ) ! Kind regards
  9. VistaLover
    ... Actually, that requirement is no longer true ... The linked report inside the official PM Forums was originally posted in mid-December of last year, as UCyborg once said , long ago in IT world time... Again, in Saturday's Serpent 52, dom.enable_performance_navigation_timing;true browser restarted (for good measure), then "the whole page GT feature" was tested: Result (you'd have to allow pop-ups from GT, first): Whether this is due to a change on Google's side or to advancements on the platform's (UXP) side, I can't really tell ...
  10. VistaLover
    ... How so? I have, since long ago, performanceObserver enabled and here (yesterday's St52 32-bit) GT works as expected:
  11. VistaLover
    ... So it's this mighty villain : https://developer.mozilla.org/en-US/docs/Web/API/structuredClone Unless I'm mistaken, this takes its place in history as the first JS "shiny" to not only be a UXP-killer, but a Windows XP/Vista killer at the same time : No browser able to currently launch under these OSes (Vista's Extended Kernel not taken into account here ) supports this natively ; and, to rephrase what's been posted above by Mathwiz, MS, in their infinite idiocy , used this piece of code to establish access to "their" downloads ; whatever happened to good ol' clickable links?
  12. VistaLover
    ... Why not document those modifications in your GitHub palefill fork ?
  13. VistaLover
    After reading the documentation, https://content-security-policy.com/unsafe-hashes/ me thinks we're blessed that "our" UXP-based browsers fail that test: ... Consistent with the documentation:
  14. VistaLover
    ... Just thought it prudent to post about it here, too (originally found in the official MCP forums): https://addons.palemoon.org/addon/wctoggle/ This XUL extension is compatible with St52 (haven't tested it on St55/NM28, but should be) and contains a button that can be put onto the toolbar (/elsewhere in the visible GUI) that, when clicked, can toggle the native WebComponents+ShadowRoot support OFF/ON; the focused/selected browser tab is being reloaded when that button is clicked (so, don't click it while typing something on-line inside that tab ), to have that tab render without/with WCs... I found the extension useful in a niche use case of mine, more about that in a future post ...
  15. VistaLover
    They fixed it in their code tree before you posted about it here. ... For those members that have not been following this, the reference made is to the "GitHub-vanishing-timestamps-bug" I first reported here, with further instances of it reported here and here ... Affected Serpent 52 versions in my case were 32-bit builds with BuildID=20230302072906 and BuildID=20230310123711; the second one was less tested, because of it being crash-prone ... The bug manifested itself when (martok's) palefill extension was disabled and native WC+SR support left at its default "enabled" state; throwing palefill into the mix resulted in adverse effects , sadly, as far as that bug was concerned... I could easily and reliably reproduce the bug, both in "dirty" and "fresh" St52/NM28 profiles; rather unfortunately, others here could not (not their fault, obviously ), so I got the sense my bug report was being doubted/disputed ... Many thanks @UCyborg for posting about it in the official Pale Moon forums; in your screengrab: one can witness the bug present in latest PM 32.1.0b3 (64-bit) ... For "closure", the bug was fixed (many thanks conveyed to the upstream dev, @FranklinDM) via merging PR #2152 in MoonchildProductions/UXP/commit/4c4bc3c, which landed in "our" tree as roytam1/UXP/commit/18e6934 ... I have been running the latest St52 (32-bit) build (ID=20230315155040) for close to 7hr and can verify that (annoying) bug as fixed ! Additional thanks for your words of wisdom below, on why running official (martok's) palefill (enabled) alongside the native WC implementation should not be encouraged:
  16. VistaLover
    You can always go to about:config and toggle "dom.enable_performance_observer" to "true"; the reason it's not true by default/already is Moonchild's objection to it ... EDIT: My post is probably redundant now , because of this ; but I hadn't got to it by the time I hit the "Submit" button (always lessons to be learnt) ...
  17. VistaLover
    "Segrite" is the brand name of the corporation that targets the Enterprise market ; Home Users are being targeted through Quick Heal: https://www.quickheal.co.in/home-users All these are paid-for products, because dedicated coders do need to make a living ... Some free tools are also offered: https://www.quickheal.co.in/free-tools Best regards
  18. VistaLover
    ... And I never implied you did anything wrong (thought to self: Why "web people" of this "era" are so "touchy" ? ) - I was directly replying to @Humming Owl, but I neglected (/deemed it superfluous) to tag him - well, now I have ...
  19. VistaLover
    ... I used it there in the sense of "Opening/Original/First Post"; see e.g.: https://www.businessinsider.com/guides/tech/op-meaning
  20. VistaLover
    ... And his "Notice" writes: https://github.com/abbodi1406/vcredist#windows-vista-notice ... And he's actually right; the last standalone file "VC_redist.x86.exe" provided by MS that will install out-of-the-box on Vista SP2 32-bit is of version 14.31.30919.0: https://download.visualstudio.microsoft.com/download/pr/8c1c2dbb-0856-4dc3-b863-b16c637bc245/E55681B9E07A58F7143E5AB5941F45DE0B485E0C9933B0CB6B702D3921F48527/VC_redist.x86.exe Subsequent versions 14.31.31005.0, 14.31.31103.0, 14.32.31302.0, 14.32.31326.0 and 14.32.31332.0 had their installers blocked from launching under Vista SP2, but their "payload"/content (various DLLs) continued to remain Vista-compatible ; next version 14.34.31823.3 had several of its DLLs contain Win7+ function calls ... So, the last of abbodi1406's vcredist AIO custom pack with full/proper Vista SP2 support is v0.6.1 (2022-06-21): https://github.com/abbodi1406/vcredist/releases/download/v0.61.0/VisualCppRedist_AIO_x86_x64_61.zip What point would there be in doing so ? Its VS2022 DLLs are incompatible with Vista and, if force-installed, would fully break all apps requiring the VS2015-2022 runtime ...
  21. VistaLover
    ... Can confirm ; the page does load, but clicking any of the download options (buttons) doesn't initiate a download ; it's JS related: What's worse, I couldn't get a download to happen with any of 360EEv12/13/13.5 and KafanMiniBrowser, so I'm not able to fetch the Edge files under this Vista SP2 x86 laptop; any working workaround will be appreciated ...
  22. VistaLover
    True, but not in the sense discussed here; in 360EEv11, navigate to "chrome://settings/advanced", then scroll further down to "HTTPS/SSL": If you press the top first button (Manage certificates...), you are presented with an OS window: a clear indication it's using the OS cert store... Now, if you click the third bottom button (with Chinese characters), you do get access to its built-in cert store, but that is only meant to be used within China, for mainly Chinese sites: What's more, the user has no edit access whatsoever to that cert store, i.e. expired certs can't be deleted, nor new ones be imported... FYI, all variants of 360EE (v11/12/13/13/5) have the same cert stores structure (access to the MS cert store + QiHoo provided one); more info about the QiHoo/360 cert store can be found at below link: https://caprogram.360.cn/#plan (in the header, select "English") Regards.
  23. VistaLover
    ... First press "Apply", then "OK", maybe?
  24. VistaLover
    ... Additionally, your OP contains below link: https://xpforever.miraheze.org/wiki/360_Extreme_Explorer which now, sadly, returns : Regards ...
  25. VistaLover
    ... How so? When you selected win2k compatibility mode in 360Loader.exe's Properties window, did you click "Apply" before clicking OK? That window looks as below under Vista (should be similar on XP): In any case, can't reproduce this here ...
×
×
  • Create New...