Jump to content

VistaLover

Member
 View Profile  See their activity

  • Posts

    2,262

  • Joined

  • Last visited

  • Days Won

    93

  • Donations

    0.00 USD 

  • Country

    Greece

 Content Type 

Everything posted by VistaLover

  1. VistaLover
    ... Well, I commented very shortly after your own post went "live" , then put the laptop to "Sleep" and went myself to bed ; when I first read your post and composed my own comment/reply to it, your post hadn't been edited yet, no screenshot had been attached at that time ...
  2. VistaLover
    ... Did you remember to also toggle "dom.getRootNode.enabled" to "true"? These prefs are actually a "wedded couple", so to speak - if one is set to true, the other has to be set to true, too - and vice versa ... ... FWIW, both I and @UCyborg mentioned, here in this thread, it's not the case ; my own advice came after the recommendation issued by upstream not to simultaneously enable both (i.e. palefill+nativeWC): UCyborg (a "hobbyist" coder, BTW by profession ) later posted additional input: ... He specifically cites GitHub above, but palefill does also include code pertaining to VirusTotal, e.g.: https://github.com/martok/palefill/commit/657b2b1 https://github.com/martok/palefill/commit/6001e31 Kind regards
  3. VistaLover
    Thanks to extensive coding work carried out by upstream developer FranklinDM, "Web Components Slots" are now supported in UXP natively ; last Saturday's UXP-builds by Roy come with that support backported ; as such, now the "modern GUI" version of VirusTotal can be successfully rendered and used in NM28/St52 without disabling the native WC implementation and without excessive CPU consumption (YMMV, here it was OK ) : https://www.virustotal.com/gui/home/upload
  4. VistaLover
    I have been running last Saturday's St52 (32-bit) build (BuildID=20230324153850) for a whole 3 days now and can confirm that the "xul.dll" crashes I first spoke of here no longer happen ; so it was indeed Bugzilla #1440809 (landing first on Fx60) that had to be applied to "our" UXP tree to get those crashes fixed... Many thanks (FWIW, don't "upstream" also need this fix, or is it specifically tied to WebExtensions ? ). Speaking of "xul.dll" crashes, another type of them (see #2176) was addressed by upstream in PR #2178, that fix has already been transferred to "our' tree and will be included in the next UXP-based releases (Sat, Apr 1st 2023) .
  5. VistaLover
    If one site hosts multiple domains, the certificate will typically include a Subject Alternative Name for each domain hosted at that site. As long as the domain you're accessing is one of the certificate's SANs, the browser shouldn't give a warning. But if the domain isn't listed as a SAN, a warning should appear. @luweitest : Mathwiz is right ; below is a capture of the "SAN field" of the server certificate on "forums.internetfreedom.org":
  6. VistaLover
    Sounds to me like another genius move by Micro$oft: make sure even fewer folks use Bing! ... It's actually their new "offspring", OpenAI-based, supposed to be "more powerful" than ChatGPT: https://blogs.microsoft.com/blog/2023/02/07/reinventing-search-with-a-new-ai-powered-microsoft-bing-and-edge-your-copilot-for-the-web/ ... And Roy's choice is: https://github.com/roytam1/basilisk55/commit/babf7e8e5c79cab7ea504f16fab609253e047ce8 => https://msfn.org/board/forum/201-browsers-working-on-older-nt-family-oses/ Quite right ; at that time, Fx did support both XUL+WE extensions, and while WE are inherently e10s-compatible, not all XUL ones had been rewritten to support it; their authors became less "enthused" (to put it mildly ) when Mozilla announced XUL support would be axed in "Quantum" (Fx57+) ... Being on Vista SP2 x86 myself, e10s is enabled in my Fx-52.9.1 (32-bit) "nostalgia/test" copy, however I don't use nor recommend myself e10s on St52/St55; the platforms (UXP Take 2 / UXP Take 1 = moebius) were significantly modified by upstream compared to their respective Mozilla forkpoints (52.6.0/53.0a1), not taking at all the underlying (but dormant) multiprocess support code into account; as posted already by others, that support was later excised completely from the "official" UXP code; "we" have kept these e10s vestiges inside "our" UXP tree, but no-one upstream (of course) or downstream (Roy) checks how well/bad these vestiges behave now, when enabled, with current UXP platform snapshots; St52 has also kept vestigial support for Fx52-level "Container Tabs" (off by default) and WEs, but, like e10s, those platform features, no longer present in official Basilisk, aren't being maintained at all by Roy... All these extra features are in a "Use at your own risk" status; for e10s specifically, you should definitely back up your profile (to have a single process one to revert to if/when things turn sour ) before enabling it, and making frequent profile backups once on e10s isn't a bad idea either ... To give credit to people requesting e10s in their browsers, it's mostly due to the way website design has grown to become over the last years : the major league of browsers, Chromium-based ones and Firefox, have, since long ago,, native multiprocess support, and it's those browsers that are being targeted by web devs and web frameworks; this has resulted in the current web abomination where every independent browser tab runs a "web app", downloading tens of MiBs of JS code that has to be rendered locally by the browser's engine; this is especially true on "popular" social media portals (facebook, instagram, twitter, etc.) and "chat" apps (e.g. Discord), exacerbated by the concurrent use of a multitude of rich media (HD images/GIFs, HD video, audio, WebRTC video+audio, etc) ... While single process engines were "fine" a decade or more ago, they're more likely to "run out of O2 and choke to death" when asked to deal with the modern web, especially on our older H/W and OSes - but do also note that e10s works best on more recent H/W, where ample RAM and CPU is being made available to the multiprocess-enabled browser core ...
  7. VistaLover
    ... I can also confirm that statement : accessing it from Southern Europe; I'm not familiar with that site, but is the server/hostname "forums.internetfreedom.org" located outside of the GFW (I assume so, because. err, "internetfreedom" is non-existent inside mainland China ) ? Since St52 has its own certificate store, XP's deficient OS CA store shouldn't matter in this case... Does the GFW block access to "fankui.dongtaiwang.net" issued server certs ? (and I see the "taiwan" string in that hostname, so it's more than probable ) ; here's a screengrab of the certs chain when validating the site's certificate: Are you able to VPN/tunnel your way out the GFW and reach that site securely? if yes, you could export the server cert (expires on June 6th 2023) and import it to St52's cert store for the duration it's valid... Have you checked whether the site loads securely on a fresh St52 profile? Have you also tried unselecting the option "Query OCSP responder servers to confirm the current validity of certificates" in "about:preferences#advanced -> Certificates" ? If you can browse SO/SU and similar sites, you'll see that solutions downgrading HTTPS to plain HTTP are not desirable and, hence, very difficult to come across (and your particular use-case is indeed a niche one) ...
  8. VistaLover
    aka Serpent 55; lethal toxicity on the official Pale Moon and/or Basilisk forums aside, I believe the very reason this: https://forum.palemoon.org/viewtopic.php?p=237897#p237897 "happened" in the first place is the existence of below about:config pref in St55: app.feedback.baseURL;https://forum.palemoon.org/viewforum.php?f=61 that controls where "Help -> "Submit Feedback..." will take the St55 user who wishes to, well , submit feedback (e.g. a bug) specific to that browser... Obviously now , the value of that pref has to change... FWIW, @pdemal isn't a username directly associated with a MSFN forum member (ofc, one may use different usernames "there" and "here" , ), but by now (and especially ever since the infamous M.A.T. "era" ), 99.9% of MSFN members do know that "forum.palemoon.org" is NOT the place to register in order to seek support for any application that launches under XP (and... Vista ) ...
  9. VistaLover
    Currently (202303242345Z), both those links return a "404 Not Found" ...
  10. VistaLover
    ... When/where did I actually said that? If on Vista SP2, go and install: ... You can't update the VS2022 runtime past v14.32.31332.0 (that's contained inside the linked AIO package), but all apps requiring VS2015-2022 runtimes should continue to work as expected with that EoS version...
  11. VistaLover
    @Rod Steel and, possibly, many others : Please be kind enough to check below FAQ: i.e. TL;DR: If a certain "feature" (Web Compatibility-related, or otherwise) has made it onto an official Pale Moon (and/or Basilisk) "proper" release, then, in all probability, it's already extant in the Roytam1 UXP-forks preceding those "official" releases ... Notable exceptions: a) The "feature" breaks < Win7 compatibility in "our" forks, hence hasn't been included ... b) (related to "a)" in an indirect way:) The "feature" is currently incompatible with the compiler used to build the forks c) "Upstream" have updated their source code (platform and/or application) on a day after Saturday and have rushed a new binary release immediately after, before coming Saturday's scheduled releases by Roytam1 ; in that last, rare, case, wait for a few more days until the Roytam1 releases have been published in the known "outlets" ... And that concludes it, I hope ... Best wishes to all!
  12. VistaLover
    ... Where the exact same changelogs (as the ones posted here) are also printed just below the download links ... This has been conveyed/explained time and again: ALL major development, both upstream and here, takes place at the platform level (i.e. UXP) Upstream (platform): https://repo.palemoon.org/MoonchildProductions/UXP/commits/branch/master Upstream (application=Pale Moon) https://repo.palemoon.org/MoonchildProductions/Pale-Moon/commits/branch/master Upstream (application=Basilisk) https://repo.palemoon.org/Basilisk-Dev/Basilisk/commits/branch/master Roytam1 (custom branch - consists of cherry-picked development commits from upstream UXP+PM+Bk) https://github.com/roytam1/UXP/commits/custom I agree that most of the committed code is in "developer's speak", but if you make it a habit of quickly browsing over it every Saturday, you start understanding more as time goes on - in any case, "Enable WebComponents by default in the platform." is human-readable enough, isn't it... Upstream make official monthly releases, with announcements in their Forum, https://forum.palemoon.org/viewtopic.php?f=1&p=237830&#p237830 in their application code repo: https://repo.palemoon.org/MoonchildProductions/Pale-Moon/releases/tag/32.1.0_Release as well as in a dedicated Releases page in the PM site: https://www.palemoon.org/releasenotes.shtml OTOH, the development model of roytam1 is akin to a "nightly" release channel, with a weekly frequency of binary distributions - these are not tagged/"official" Roy releases, just "unstable/weekly" ones; the "norm" in such cases is to provide changelogs in the form of git-compare, e.g. : https://github.com/roytam1/UXP/compare/6f99b97...85f6a49 lists the source code changes between the latest UXP builds (by Roy) and the ones he released some 10 days ago... It's the way it has been for years... Of course I can be wrong, as much as anyone can ... And I'm not in the habit of "lying to myself", or to others, for that matter... In fact, being past 50 has taught me that it's telling the truth to others that will get me to trouble more often than not... I'm simply volunteering here, my free time is as precious as yours or anyone else's inside this community... Roy's making the hardest sacrifice to keep our old H/W and OSes usable by providing his browsers, I consider it a form of payback (to him) to occasionally offer "my services" here, with the deep knowledge I'm not "pleasant" to ALL readers... Best regards...
  13. VistaLover
    And my question is: Where have you been? Upstream's native WC implementation has been backported to UXP-based browsers by roytam1 (these, of course, include New Moon 28 - but NOT NM27) since the builds released on the first weekend of March: https://msfn.org/board/topic/184051-my-browser-builds-part-4/page/55/#comment-1239941 ... Roy spends considerable free time composing and putting up those Release Notes every Saturday but it appears, in practice, they go totally unnoticed by the majority of users here ; and it's a pity, TBH ... TL;DR: Grab yourself last Saturday's NM28 build and you'll see "what you really want to see"; BTW, since the native WC implementation is still being perfected, don't forget to update to the future NM28 releases as they become available ...
  14. VistaLover
    ... AFAIAA, you need install neither (for simple tasks), because, if you're on a very recent and powerful browser (e.g. ChrEdge x64), you can do most GitHub stuff on-line, via their native on-line File Editor - also, you can try their "New Code Search and Code View" feature: (not 100% compatible with latest UXP, but mostly works ), which can also take you to their "new", powerful, repo managing tool (aka "Web Editor") served from "github.dev" (this is NOT compatible with UXP, as it uses the "??=" operator ): https://github.dev/UCyborg/palefill/blob/master/bootstrap.js Thanks ...
  15. VistaLover
    @msfntor Thanks for your replies and provided links therein ; 90% of the info is known to me, another 5% had by now faded in memory ... However, and perhaps my wording was a bit off , what do the Chase.com IT staff expect from one of their web-banking customers? Should one use a completely fresh browser profile, devoid of any browser extension, when logging into this bank? Of course they can, probably, tell when extensions are installed in the customer's browser (which should be true in most instances), but do they outright forbid access when they detect "third party" extensions? And what do they mean by "third party" as opposed to "first party" ones (and which "first party" ones they do support, and what does that really mean)? Hence my original question:
  16. VistaLover
    ... While following the link posted by @gerwin above, I ended up loading below article: https://www.winhelponline.com/blog/disable-full-row-select-explorer-windows-7/ I was (and still am now) on latest Serpent 52.9.0, but, to my dismay , I regrettably found out that images in this article aren't being displayed AT ALL in St52 ; I had to launch a Chromium variant (360EEv12) to be able to see the images, which constitute an important part of the article... Is this a known "Google-ism" that UXP currently lacks? St52's Web Console has a "ReferenceError" and a "SyntaxError" in red lines: ReferenceError: event is not defined[Learn More] https://www.winhelponline.com/blog/disable-full-row-select-explorer-windows-7:167:213 SyntaxError: bad method definition https://www.winhelponline.com/detroitchicago/cmbv2.js:197:336 "Fixes" are gladly welcome ...
  17. VistaLover
    ... Probably enabling the (mostly "fixed" ) native WC+SR support in St52 (and backported to St55) is what allowed you to sign-in suuccessfully to Chase.com using St55... Fx 98 and Chrome 95, actually ... Latest St52 comes with a built-in SSUAO for chase.com: general.useragent.override.chase.com;Mozilla/5.0 (%OS_SLICE% rv:79.0) Gecko/20100101 Firefox/79.0 I'd suggest changing it to general.useragent.override.chase.com;Mozilla/5.0 (Windows NT 6.1; rv:102.0) Gecko/20100101 Firefox/102.0 where 102.0 is current FxESR and chase.com don't allow anything older than Win7 ... Should at least rid you of the "Please update your browser" ribbons, until the "real" breakage takes place... (FWIW, their sign-in page is served from "secureXXea.chase.com", but the SSUAO takes care of that, too...)
  18. VistaLover
    ... And what exactly does this mean. even? In what way are browser extensions involved when one tries to access "chase.com" ?
  19. 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 ...).
  20. 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 ) ...
  21. VistaLover
    In Violentmonkey, I don't use myself: // @match *://*/* but rather: // @include *
  22. 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 ) ...
  23. 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 ...
  24. 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 ...
  25. 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
×
×
  • Create New...