Jump to content

VistaLover

Member
  • Posts

    2,105
  • Joined

  • Last visited

  • Days Won

    93
  • Donations

    0.00 USD 
  • Country

    Greece

Everything posted by VistaLover

  1. ... I'm so frustrated to hear about this ... The issue I reported (empty "Applications" tab/window) happens on ALL of my roytam1 browsers here (St55/St52/NM28); all these are the latest 32-bit releases, OS is (as has always been the case ) Windows Vista SP2 x86; can other MSFN members try this, too? ... "Can get" ? It's always empty for me here Sure; below a screengrab and copied text from latest NM28 (32-bit): Timestamp: 17/11/2023 13:56:21 Error: NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIMIMEService.getFromTypeAndExtension] Source File: chrome://browser/content/preferences/applications.js Line: 1064 ... Hope it's useful to you ...
  2. @roytam1: Possibly related and it is indeed a serious regression: the "about:preferences#applications" internal browser tab ends up empty in latest versions of both St52/St55, thus the user can no longer customise the default browser actions related to the content-type of downloads ; below is a screengrab from a fresh St52 profile: Additionally, though NM28 doesn't have an "about:preferences#applications" internal browser tab, the corresponding "Preferences -> Applications" window exhibits the very same bug : So, this is probably a platform (rather than an application) bug, which has to be identified and mitigated... It's very early in the morning in my timezone, apologies but I can't present to you at this time a regression window ... Hoping for an easy fix (fingers crossed) ...
  3. Hello ; do you think https://repo.palemoon.org/MoonchildProductions/UXP/commit/e4643f5bed2cdc600fc29900fe3b4d22e25763bc is the culprit, hence you did this: https://github.com/roytam1/basilisk55/commit/9bd1d38f77d2c01548f8802c369368e68ca08911 ? I'm no coder myself (everyone here knows that ) , but I had more time now to study Mathwiz's report, specifically: The issue is specific to the native downloader and the "open file" function - the file here being an "installer" binary which needs to be executed by the browser; the 7-zip installer comes in two varieties, EXE & MSI, so it would be helpful to clarify which - in any case, my own eyes fell on this: https://repo.palemoon.org/MoonchildProductions/UXP/commit/98c3aa57431c4b158c750dfabfd0ab90708ebf16 which you ported both to UXP and Bk55 trees: https://github.com/roytam1/UXP/commit/74a4260ecd6b6e6f40d48d4b181e34127487532b https://github.com/roytam1/basilisk55/commit/a406edc82008cf5b4fba914b73929a9933065319 Both of these first landed on the 2023/10/28 respective releases ... Speaking purely for myself , I think it's a bad practice to let the browser run executables; if it's installer packages, I strongly prefer to first "properly" download to disk and then archive them; many a times I've been bitten by a new application "update" that broke things for me and had to restore the previous version via its archived setup (often times no longer retrievable from the vendor); as for the actual installation step, I tend to exit all not-needed apps (including browsers) and then manually launch the setup - perhaps I interpret the "law" very "strictly" ...
  4. ... You're welcome ; à propos, you may want to correct that double negative there , else one may assume you do use Vista (joking, ofc) :
  5. ... This is not a correct assumption , and I think I have mentioned this issue in passing in the past, possibly in another thread (that I'm too lazy now to dig up ); the implementation by cmalex (ProxyMII_v230813) employs a specially crafted/patched edition of CPython 3.7.11 (based on the initial 3.7.1-XP implementation by Dibya), which runs specifically only under WinXP SP3 x86; when the python37.exe binary is launched under Vista SP2 x86, it throws function errors: The DLLs enclosed inside the red rectangles are foreign to Vista and are, in fact, loans from OneCore API, Wine and/or ReactOS projects, while several DLLs/EXEs inside the "python" directory have been HexEdited to point to these DLLs, which, in essence, port some NT 6.0+ kernel functions to XP SP3 (see some analysis here) ... OTOH, default CPython 3.7 x86 (as distributed by the PSF) can run natively under Vista SP2 (but NOT under XP SP3), being, sadly, the last CPython version that works there; default CPython 3.8 requires Win7+, default CPython 3.9 requires Win8.1+, etc. ... Hope it's clearer now (... and since this is an "XP audience" thread , I didn't want to share additional "Vista-details" here, but since you brought it up, I indulged ) ... Happy Thursday evening to you!
  6. As a FYI , even when using very recent versions of ProxHTTPSProxy, several fields in the https://browserleaks.com/tls detection page apparently don't work with the IEx severely outdated Javascript engine ; I have developed a Vista SP2 x86 targeting edition of ProxyMII (based on the original work by cmalex ), which uses: ProxHTTPSProxyMII-v1.5 (python script) CPython-3.7.17 x86 (EoS for py3.7) cffi-1.15.1 (EoS for py3.7) colorama-0.4.6 cryptography-41.0.5 pyOpenSSL-23.3.0 PySocks-1.7.1 urllib3-1.26.18 (script incompatible with urllib3 >=2.0.0a1) and when IE9 is configured to use it, the sections Protocol Support, Mixed Content Test and TLS Fingerprint remain empty: Best regards
  7. Greetings ; IMHO, it'd have been a service to this community if you had actually named that "streaming service" for which Mypal68 doesn't work, because you would've saved some other MSFN members the "hassle" you yourself went into ... According to my own investigations, the more prevalent audio streaming services (Spotify, Apple Music, Tidal, Amazon Music) use in-browser DRM (largely Google's WidevineCDM), with the notable exceptions of Youtube Music and deezer (those two use different methods for protecting their audio streams ) ; I'm not very familiar with the codebase of Mypal68, but AFAIAA it doesn't support DRM; even if it did inherit the DRM support extant inside Mozilla Firefox 68, its initial fork point, the Widevine version supported by Fx68 has been long deprecated/blacklisted by Google and their WV licence servers - besides, Google make sure their blackboxed Widevine DLL only runs on Win7 SP1+; and even Win7 is going to be deprecated by Widevine, once Fx115esr reaches its EoS ... As for AstroSkipper , I'm absolutely confident he double- and triple-checked those links at the time his post went live, because that's how much meticulous he is on such matters - it would be unrealistic to expect of him to (occasionally) check the validity of the links post-submission and, indeed, the fact they were removed by Mypal68's author soon after was quite unexpected, TBH ...
  8. You're welcome ... How so? Aren't you subscribed to this thread? That was my gut feeling, thanks for the confirmation ... The first, older, pref "security.fileuri.strict_origin_policy" was inherited by UXP from Mozilla ESR 52; the second one you cited, "security.fileuri.unique_origin" is a newer one, implemented by MCP in 2019: https://repo.palemoon.org/MoonchildProductions/UXP/commit/33b6f178d16f94df7de98d1316f563f14a2bedd5 with a clarifying comment written in: https://repo.palemoon.org/MoonchildProductions/UXP/commit/408ca49a029efa54d18234288c04944d2905fecb The original PR#1196 that implemented this pref has, apparently, been lost now, amidst their migration from GitHub to Gitea ... It is my conviction that MCP tried to replicate Bugzilla #1500453->#1558299 of that same period, although Mozilla chose a different name ("privacy.file_unique_origin") for the pref: https://hg.mozilla.org/mozilla-central/rev/2ad059cc9e78 That Bugzilla entry aimed to patch CVE-2019-11730 , but the default pref value there was "privacy.file.unique_origin;false", whereas in UXP it's "security.fileuri.unique_origin;true"; I'm not an expert on security, nor a coder, so can't advise you which of the two UXP "security.fileuri.*" prefs to toggle for your use case; from the Pale Moon v28.6.1 Release Notes: so I tend to think toggling only that newer, second, one might be preferable; toggling any of the two (permanently) lowers your browser security; a Mozilla expert advises to create a separate browser profile exclusively for such use cases ; in conclusion, Mozilla have removed "privacy.file.unique_origin" in Fx95+ and "security.fileuri.strict_origin_policy" is also to be axed (if not already); another case of them "foolproofing" their browser, in their effort to save their users from self-harm ...
  9. @roytam1 : This week, upstream have merged some additional "aspects" of UXP#2346 ; since we've kept EME in our tree, am I right to assume those upstream commits should be exempted from merging? FWIW, some few sites do still use ClearKey (soft) encryption, also part of EME; some other sites delivering both Clear and DRM'd media content would not load at all if they sniff out the browser doesn't support EME/DRM; so, even if used solely as an indication of "sites-requiring-Widevine", I still feel keeping the (mostly broken) DRM implementation in Serpent 52 is a "good" thing... Also, UXP#2281 is being pushed; will that impact buildability/NT<6.1 compatibility for "you"? Thanks for your stupendous efforts ...
  10. Actually, something relevant was discussed a few pages back: 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: I don't have HTTrack installed here, so can't test now on your behalf ...
  11. ... QT Player v7.7.9 (file version 7.79.80.95) for Windows is the last one Apple released for installation under Vista SP2/Windows 7 SP1; the EXE setup has a SHA1 digital signature from way back in Dec 16th, 2015, so quite outdated ; that same installer won't even work on Win10+, unless you hack it yourself ... Since the recent discussion here was about the QT browser plugin, even that isn't installed by default: My Serpent 52.9.0 copy does pick up the QT-v7.7.9 browser plugins under both "about:addons => Plugins" and "about:plugins", but, since I have now no actual use for it inside my browser (for online content), I have it permanently disabled ...
  12. ... We're again steadily drifting off-topic , but, e.g., https://www.nbcnews.com/tech/elon-musks-business-ties-china-draw-scrutiny-twitter-purchase-rcna26057 https://www.nytimes.com/2022/04/29/technology/elon-musk-china-tesla.html @mina7601 : Are you into world politics at all (given your young age) ? Greetings ...
  13. In latest Serpent 52, I didn't have to toggle that pref to enable successful loading+rendering of either https://www.elektroda.pl/ (Polish version) or https://www.elektroda.com/ (English version); creating SSUAOs for both domains, impersonating the latest FxESR, did the trick for me : general.useragent.override.elektroda.pl;Mozilla/5.0 (Windows NT 10.0; rv:115.0) Gecko/20100101 Firefox/115.0 general.useragent.override.elektroda.com;Mozilla/5.0 (Windows NT 10.0; rv:115.0) Gecko/20100101 Firefox/115.0 Seems like another case of their UA-sniffing scripts rejecting "unfamiliar" slices ... Best greetings !
  14. FWIW, the same stands true for pre-Quantum Firefox Complete Themes, too : https://github.com/JustOff/ca-archive/issues/28 https://github.com/JustOff/ca-archive/issues/63 and some later comments on the matter: https://github.com/JustOff/ca-archive/issues/58#issuecomment-1278351039 https://github.com/JustOff/ca-archive/issues/58#issuecomment-1283141327 FWIW, I've never been a "persona" person myself (pun intended ), but had since the very start opted for Complete Themes - Mozilla hunt them down even before they removed the "legacy" lightweight ones; at first, personas were dubbed "themes", whereas the real "themes" were dubbed "Complete Themes" and made harder to locate on AMO; ultimately, Complete Theme authors practically gave up even before the advent of Quantum, because every newer Fx release broke, in several ways, the latest (complete) theme version, which then had to be reworked extensively to remedy the Mozilla inflicted breakage ...
  15. Hello there ; I became aware a while ago via this reference below (in another forum thread ) : ... and I can still verify this today: Can a member of the mod team kindly share some additional info with regards to this decision? Is it something temporary and if yes, how long will this measure last for? I'm not that preoccupied myself though , if anything, it'll stop "persons" from further "cloning" their MSFN accounts (you know, those ones that many existing members - including me - are convinced they exist, but no-one, including the mods, can, beyond doubt, prove they belong to the same physical person ), still it'd be welcome if some clarification on its implementation was communicated to plain members... Kindest regards (BTW, Happy Halloween to those that observe it!) .
  16. Greetings ; back in the glorious days of "proper" Mozilla Firefox, one of your compatriots had created the stupendous extension called "Add to Search Bar": https://firefox.maltekraus.de/extensions/add-to-search-bar The extension's XPI file (last version for Serpent 52 is 2.9) can be found inside the CAA ; since years ago, I had created myself specific MSFN Forums search engines via that nice extension - e.g. for this very forum: A popup appears, where you have to approve or edit the proposed SE name (and optionally add a keyword for that engine): and then you have your new MSFN SE: Best regards.
  17. https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID "Upstream" just implemented this natively in UXP: https://repo.palemoon.org/MoonchildProductions/UXP/commit/3d92b8212595769c40da7ccfbafb3898cfaaf7bd Thanks @basilisk-dev ...
  18. OT: I seriously doubt that Firefox Nightly 117.0a1 build you reference has the "WebP patch"; https://thehackernews.com/2023/09/mozilla-rushes-to-patch-webp-critical.html CVE-2023-4863 landed on Mozilla Firefox 117.0.1, this is the stable/release channel of the browser, coming after initial stable release 117.0; 117.0.1 was what's "affectionately" called by Mozilla a "chemspill" release, https://wiki.mozilla.org/Release_Management/Chemspill i.e. the patch wasn't extant in the "upper" unstable channels (beta/dev, nightly) when it was first applied in their trees; at the time Fx stable was on v117.0, beta/dev was on v118.0b and nightly was on v119.0a1 - too late for deprecated 117.0a1 builds, which had served their purpose when the WebP vulnerability was made public... Last moment (before submission) addition: I located the post you mentioned: https://msfn.org/board/topic/185870-i-found-the-latest-build-of-firefox-nightly-that-works-on-windows-7/?do=findComment&comment=1253973 If you notice the Mozilla FTP link contained there, the Nightly 117.0a1 build you talked about has a build date of 2023-07-14, thus it doesn't contain the WebP fix, which was only applied on 2023-09-12 (two months after that build was compiled+uploaded) ...
  19. Personally, I avoid Discord with a passion, because it really is unsuitable for old/under-resourced H/W like the one I'm currently on ... Additionally, all these Chrome-targeting chat services run sub-optimally on UXP, even on recent/supported H/W... Your main query has been answered here many a times, and (besides Discord) also encompasses similar services - Discord uses WebRTC for its audio and/or video features: https://sukhadanand.medium.com/how-does-discord-scale-to-5-million-concurrent-users-ed0874063fd but WebRTC, since the very beginning, was never supported by upstream in their PM browser (the same stands true for NM28); Serpent 52/55 do come with WebRTC enabled but, the last time I heard, their implementation is still eons behind the current iteration Discord etc. feel comfortable with... TL;DR: Discord are right from the start: Unsupported browser (you can still use text-based functionality, though) ... Since you appear to be on Win11, plenty of "workarounds" are available to you, just not for a UXP-based browser...
  20. ... That same question was already raised: I suspect it'd be difficult to find one which uses the exact code US bank "chase.com" uses; in the upstream forum, they have several members who are Chase customers, but the @Mathwiz solution has already made it there ; obviously, for a native UXP implementation, either here or by MCP, a dev must be granted access to a chase.com account (perhaps someone in the US can open an "empty" such account for the purposes of this WebCompat issue ), if "no-login" alternatives aren't found in the near future...
  21. ... I get you , but... At least the ones containing polyfill code aim to implement JS features not natively present in "the browsers able to run on older Windows NT-Family OSes"; for the rest of those userscripts (e.g. the youtube ones I posted two years ago ), I'd claim that even the Windows XP subforum isn't a suitable "place"; perhaps start a new thread inside this very subforum with just the polyfill-based userscripts? In any case, it's not up to me to decide if/where that topic gets transferred to - I just wanted to emphasise my observation/point that those userscripts aren't exclusive to Windows XP ...
  22. Pity that the "topic" is inside the Windows XP subforum ; IMHO, it should be transferred to the "Browsers working on Older NT-Family OSes" subforum (where this very thread resides ); but I know, I'm just a minority Vista user myself ...
  23. IIANM, structuredClone() has been already implemented in UXP in the recent past, https://repo.palemoon.org/MoonchildProductions/UXP/issues/2197 so, perhaps, @Mathwiz stands a good chance of having chase.com (after signing-in) work in latest Serpent 52 and/or NM28 ...
  24. Try these links, from their SourceForge mirror: 64-bit: GoogleChromePortable64_98.0.4758.102_online.paf.exe GoogleChromePortable64_99.0.4844.84_online.paf.exe 32-bit: GoogleChromePortable_98.0.4758.102_online.paf.exe GoogleChromePortable_99.0.4844.84_online.paf.exe As you might be already aware by now , these online installers need to fetch stuff from Google servers, but versions 98/99 are relatively recent to have been wiped out from Google CDNs... Regards .
  25. In the case of GitHub, and I'm talking here strictly about a dark vs light theme, not the new "Global Navigation Update ", they respect the browser's default/custom setting (provided the browser has such a setting) with regards to anonymous visitors. In Serpent 52, that setting is: browser.display.prefers_color_scheme and when left to its default value of 1, GH will serve their Light Theme to (anonymous) visitors; change that pref to a value of 2 and they'll serve their Dark Theme... A signed-in GH member can control the type of Theme served via custom "Appearance" settings inside his GH profile, where more than two Theme selections are offered, and can thus override the aforementioned browser setting... In contrast to GitHub, GitLab only offer their anonymous visitors a Light Theme variant (see my previous post); to change that, you'd have to sign-in ...
×
×
  • Create New...