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. https://repo.palemoon.org/MoonchildProductions/UXP/commit/1f32c17fcf767a366b1547f51fccc7dcb13ff719 https://repo.palemoon.org/MoonchildProductions/UXP/commit/ffdba3d91e0ca7df003a97f564451fb0ae97fa8e ; hopefully will arrive in coming weekend's roytam1 builds ...
  2. ... Actually Fx v79.0 , as per the linked documentation ; it was Opera (adjacent to the Fx column) that implemented "??=" in its v71.0... Since 79 is even further from 68 (than 71), it probably makes things for a native implementation in Mypal68 more difficult ...
  3. Regarding the recent discussion about discourse-based forums being BROKEN under UXP-based browsers (NM28/St52/possibly also St55/moebius), I found a related thread in the official PM forums: https://forum.palemoon.org/viewtopic.php?f=70&t=29327 The point in the thread where the recent breakage happened (i.e. implementation of the "??=" operator by Discourse) is this one ; the approach savvy members there took to address the breakage is to use JustOff's Modify-HTTP-Response (legacy) extension below: https://github.com/JustOff/modify-http-response/releases/tag/1.3.8 Once installed, go to "about:addons" and access that extension's options; locate the "Filters" input field; in the initially empty field, paste the code below: [["/global\\.discourse-cdn\\.com|community\\.(frontrowcrew|cartalk)\\.com|forum\\.(manjaro|openwrt)\\.org|forum\\.italia\\.it/",["/browser-detect-/",["/.*/g",""]],["/vendor-/",["/(t\\.discourse\\.hoisted|t\\[e\\]|r)(\\?\\?|\\|\\|)=(\\{\\}|\\[\\])/g","$1$2($1=$3)","n??=[]","n||(n=[])"]],["/discourse-/",["e.draft||=t.draft","e.draft||(e.draft=t.draft)","/(t\\.__registry__\\._typeInjections\\.service|[ne]|f\\[e\\])(\\?\\?|\\|\\|)=(\\[\\]|\\{\\})/g","$1$2($1=$3)"]]]] NB: You'd better use a proper code-editor to copy/paste, to avoid any errors... Then "tick" the "Enable" setting above the "Filters" input field... @msfntor : If you now visit https://community.brave.com/ in your UXP-based browser, (hopefully) the forum will load OK (it does here, with St52): I do hope you're happier now ... The inner-workings of the method is that the extension intercepts the UXP-incompatible JS code sent by Discourse and then transpiles it on-the-fly, based on the Search-and-Replace RegExp filter specified... All credit for the filter code belongs to PM-Forum members Kris_88 and adoxa ... @Art7220 : The procedure I detailed above seems to also work for your "own" Discourse-based forum: https://forums.mst3k.com/
  4. Yes I did; please understand I don't harbour a "negative disposition" towards you, nor am I out there to insult you ... But what was the point in the context of this recent discussion to mention that the homepage https://www.sitepoint.com/ loads (scrolls) OK in DCB? "Discourse" is a "forum" platform, so I had expected you to link/refer to their actual "community" page, https://www.sitepoint.com/community/ which is indeed broken in DCB (I assume? ) and UXP...
  5. ... Wrong again ; their Homepage doesn't use "Discourse", but their Forum does : https://www.sitepoint.com/community/
  6. ... As you have already discovered, it's the same issue as this one ; my suggestion to you in my previous post on this thread still stands :
  7. ... And: https://community.brave.com/ (courtesy of @msfntor ) ...
  8. ... What it says on the tin: a) We (intend to) ONLY support "last week's" iteration of the Chromium engine ... b) You can forget "the previous 10 years of the Internet" , thus ALL browser engines that are still compatible with that Internet "snapshot" ...
  9. ... Leave that envvar empty/don't use it at all, so that your ISP connection is used DIRECTLY for the cert revocation check (which is performed over plain HTTP); in any case, only the secure connections the game attempts should be redirected to the TLS proxy, i.e. ONLY the HTTPS_PROXY envvar should be used... Just my 2c, of course...
  10. ... Their forum is based on the discourse platform, but "discourse" have recently implemented another UXP-exterminator, the operator called "nullish coalescing assignment ("??=") : Your only hope under XP is to use 360EEv13.x/minibrowser to load that forum, because that operator was first implemented in Chromium 85 (Firefox 79) ... Most sadly , "discourse" is being used by many forums/communities, so this is just going to only escalate in the coming days ...
  11. HULU (a US-only service, BTW) uses DRM exclusively for all of its streams... Unlike Netflix, where a fallback to using the Silverlight NPAPI plugin for "legacy" browsers is in place (correct me if wrong , at least that's my recollection of things on Netflix ), HULU demands the WidevineCDM (owned by Google ) to properly function... WidevineCDM is currently incompatible with the Windows XP/Vista OSes (and in the far past was only compatible under XP with the Google Chrome web browser); if on Win7+, you must use one of the latest Chromium variants and/or latest Firefox to watch HULU ... BTW, NM28 does not support DRM on any OS, while St52 supports DRM on Vista+; however, the version of WidevineCDM it ships with (and supports), v1.4.9.1088, has been deprecated by Google, i.e. it can't acquire decryption keys from the dedicated Widevine lic servers ... @Art7220 : Got an Android phone? If yes, download their app and watch HULU's DRM streams there ... As you can see, Google not only control which webpages you can successfully load in your (non-Chrome) browser, they also control which rich content is available there, too (and also demand you update your OS to watch it) ... A true dictatorship, if you ask me...
  12. Respectfully, I beg to differ ... Google do come up with new JS drafts and are very swift to implement them into their own browser monopoly ... Adherence to well-established web standards is a lesser concern to them - they practically control themselves the W3C board, so everything "new" and "fancy" they devise will find its way into a "revised"/updated Web Standard ... TL:DR: Google aren't better at "complying" to web standards; they "own" "www" with their monopoly and can do "as they please" with web standards... As the majority of current mainstream browsers are Chromium-based, what Google do dictates what the rest are forced to do... Mozilla are funded by Google, their "current" Gecko engine aspires to be a Chromium fork; so, Firefox also adopts what Google have already implemented a while back into their browser (a policy known as "Chrome-parity") ... That leaves ALL the rest browser choices (non-Chromium/non-Firefox) lagging behind in Web Compatibility...
  13. ... Well, those builds use a CPython 3.7.1 version "hacked"/patched to work specifically on WinXP, ONLY (whereas official CPython 3.7.x, by the PSF, requires WinVista as minimum [client] WinOS) ... The PSF EoS'ed WinXP SP3 with the CPython 3.4.x branch; this patched py3.7 compilation borrows modified "system-like" files from either Wine/ReactOS/OneCore API (not sure exactly which ) projects (files bcrypt.dll, kernelXP.dll, ntext.dll, psapi.dll, ws2_xx.dll), which specifically target NT 5.1 and aim to backport missing functions from NT 6.0 (where py3.7 runs natively ) . It's the same (type of) CPython 3.7.x "hack" that is incorporated into the latest ProxHTTPSProxy versions (maintained/released by MSFN member AstroSkipper); this nice project runs successfully ONLY under Windows XP; for Vista [and higher, though Win7 updated to EoS shouldn't need ProxHTTPSProxy ], the embedded Python has to, somehow, be switched to one of the official py3.7 releases...
  14. Is this something upstream should be notified about , or do the crashes happen because: a) "our" UXP tree has significantly diverged from upstream's? b) upstream target MS VS2022 compiler for their Windows builds (themselves targeting Win7SP1+), whereas "we" still target MS VS2015 and WinXP+ ?
  15. ... Do you happen to know the last (portable) version to do so, additionally the last one for Vista? EDIT: It appears the last Vista-compatible release was v0.6.3 : based on Chromium 85; when the author upgraded to Chromium 86 core, Vista support was lost and he could not restore it ... Also:
  16. Official Pale Moon 32.0.0 Language Pack can be installed in latest NM28 if "install.rdf" is edited (lower <em:minVersion> to accommodate NM28); it works for the most part: Sadly, some less-used parts of the GUI (e.g. Web Developer Tools) are partially broken... This is because PM and NM[28]'s LPs are no more fully interchangeable... FWIW, all Roy's browsers are meant to be "en-US" locale, only...
  17. "Personally", I'd stick with whatever browser on Win7SP1 is based on Chromium 109 (EoS for that OS), for as long as it still meets my browsing requirements ... ALL the forks to be found here in this thread basically target WinXP/Vista and even the UXP-based ones (NM28/St52) still fall considerably behind, web-compat-wise, Chromium 109 (and are very unlikely to catch up with it in a timely fashion, if ever...). I'd also keep an eye on the Win7 "communities" and the Chinese browser market (), as was the case with XP until recently , some Chromium 109+ codebase is bound to be backported to Win7... Additionally, there's promise in the air for a "Win7-Extended-Kernel", so not all things are "doom-and-gloom" ... FWIW, Mozilla Firefox still supports that OS, with no official cut-off date announced yet...
  18. No (the site employs dynamic module import, "import()", very unlikely to be implemented in UXP platform any time soon ) ... ... Of course it does! https://caniuse.com/es6-module-dynamic-import
  19. ... Thanks ; so, does that mean the Wiki article I referenced is at fault?
  20. @msfntor : The good news (be it OT here) is that https://www.darkreading.com/ does load in latest Serpent 52 , however the font they're using does not render well: The solution is to block "remote fonts" in uBO: Back on topic, as much as you (or @XPerceniol for that matter) are enamoured with your DCBrowser , the hard fact remains it (the last XP-compatible version) is based on Chromium 75, whereas all the 360EEv13.x varieties are based on Chromium 86; mind you, "86" is now considered quite "old", too, with Google Chrome being at version 109 (and higher versions even dropping support for Win7SP1 ) ... I can easily replicate your issue with 360EEv12 (Chromium 78 based): Javascript Console error is enlightening: Syntax error is generated because the site (rather a framework the site depends upon) requires support for "?.", the optional chaining operator, first implemented in Chromium 80 (hence why 360EEv13 works ); sadly, operators can't be polyfilled (only transpiled, but at a very steep cost to performance ); nothing that would help your very aged JS engine of DCBrowser, am afraid... In the future, it'b be best to accept that webpage rendering issues in DC are due to it being obsolete when it faces the web of 2023+; make provisions to migrate to something newer (browser, OS, whatever...); this is a hard reality the majority of us face currently... Bon après-midi ...
  21. ... But the original query there was about "32-bit application support", which I assumed to mean "32-bit application support" under a 64-bit (Vista) OS ... And I believe the screenshot there relates to such a use-case (just take a closer look at the UA...) .... Being a user of 32-bit Vista myself, I'd be the first to welcome any good news about Vista ExtKernel supporting the 32-bit OS archictecture, but it seems we're not there yet...
  22. ... Both official applications (Interlink Mail & News by Binary Outcast and IceApe-UXP by Hyperbola) build upon the official UXP platform, which itself spawned from the Mozilla Firefox 52.6.0esr platform... Roy had already forked his own "smorgasbord" version of UXP (where XP/Vista support was reinstated), so the release of the Mail News and Iceape forks was just a matter of adapting the front-end codebases to his own version of UXP... FTR, there's also Icedove offered, a fork of Icedove-UXP ... Common denominator here being UXP ... ... I don't think this is intentional, if it is a thing at all, but rather a consequence ... When the SM 2.49.x branch was still alive, members here did talk about it, but when the SM devs had no other option but to move away from it to a fresher codebase, sadly no longer compatible with XP (/Vista) (popular "among these parts of the community"), the "interest" of members here inevitably waned ... Probably this ; whatever the Gecko version SM builds upon, it still uses Rust, and for someone "here" to "potentially" attempt an XP backport, he/she must find a way to backport that "Gecko version" to XP first, before dealing with the SM front-end code... That's why I mentioned Feodor[2] previously... Unless we're talking about a SM 2.49.6+ application patched to build upon Roy's UXP platform; but that wouldn't be much different to existing Iceape 52, would it?
  23. @Reino Please read (and follow contained GH links) below GH comment: https://github.com/JustOff/github-wc-polyfill/issues/71#issuecomment-1403998251 In short, the first extension has now become an abandonware; its last maintainer recommends migration to the second, which has a "broader" application (not limited to GH/GL) ...
  24. ... You're probably mixing it up with WaterFox Classic , which is indeed based on Fx56 ... SM 2.53.x branch is forked from a Firefox ESR 60.x code snapshot, specifically SM versions > 2.53.4 are based on FxESR 60.8 ... https://en.wikipedia.org/wiki/SeaMonkey Feodor (a one-person "act") has managed to port FxESR 68 to WinXP/WinVista via his MyPal 68 project, though that involved using a custom, XP-compatible, version of the Rust coding language ... If the SM project are to take a similar route, then backporting SM 2.53.x (FxESR 60.x-based) to WinXP/Vista doesn't "sound" unfeasible... But I seriously doubt they'll be interested ...
×
×
  • Create New...