Jump to content

VistaLover

Member
 View Profile  See their activity

  • Posts

    2,243

  • Joined

  • Last visited

  • Days Won

    93

  • Donations

    0.00 USD 

  • Country

    Greece

 Content Type 

Everything posted by VistaLover

  1. VistaLover
    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 !
  2. VistaLover
    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 ...
  3. VistaLover
    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!) .
  4. VistaLover
    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.
  5. VistaLover
    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 ...
  6. VistaLover
    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) ...
  7. VistaLover
    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...
  8. VistaLover
    ... 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...
  9. VistaLover
    ... 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 ...
  10. VistaLover
    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 ...
  11. VistaLover
    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 ...
  12. VistaLover
    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 .
  13. VistaLover
    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 ...
  14. VistaLover
    It's worse than that ; the sign-out option (not a button anymore, either ) is tucked away inside one's "avatar" menu, which now opens as a right sidebar: OT : On the 360EEv13+ variants (which have better support for GH compared to current UXP-based browsers), my "avatar menu", instead of opening as a right sidebar, travels all the way to the left and displays as a left sidebar; this is annoying, because I then have to move the mouse cursor towards the left (vertical) tab border to access that menu's entries ; can others reproduce? A fix for that would be most welcome! Yes, most sites (including GH) want you permanently signed-in, so that they would track/monitor you more efficiently ... I do spend a lot of online time on various GH pages and need to use members-only features (e.g. comment on issue trackers, react to comments, download GitHub Actions artifacts, etc.), and what with the "hoops" of signing-out and then signing back in (especially when your ISP has "given" you a new dynamic IP address in the interim ), I tend to stay mostly logged-in and protect those signed-in GitHub cookies in my browser profile via a dedicated extension... BTW, GitLab also serve different CSS files to anonymous visitors Vs logged-in members: Signed-out: Signed-in (dark theme offered/selected): You are shown the "default" vendor selection for a said site permission when the "Use Default" square has been ticked; e.g., for "Access Your Location", the default permission is "Always Ask" (and that default is again stored inside permissions.sqlite); if the user unticks the "Use Default" box, then he/she(/they-them ) can choose one of the two other (non-default) available selections (i.e. Allow/Block), which are now non-greyed-out; finally, ticking anew the "Use Default" square will reset the permission to "Always Ask" and grey-out the other two...
  15. VistaLover
    As posted already, file "Login Data" inside 360EE's profile is where login credentials for user accounts are stored; the file is actually of the sqlite format, but without that file extension (in contrast to Mozilla Firefox, where similar files come with the .sqlite extension); inside that file, ONLY actual password strings are being encrypted, not the sites for which you have created accounts for, nor the actual usernames/e-mails you're using on those sites to log-in; so, be careful with that info, too ... Password string encryption is tied to the machine/OS where the password was first saved/created, because parts needed for their decryption (salt?) are stored, encrypted, inside the host's registry; this is different to Mozilla Firefox, where you just need logins.json+key*.db profile dir files to transfer account credentials between Firefox profiles! In any case, profiles in recent Chromium versions are really not portable across different machines ... 360EE also doesn't offer you an option to actually see saved passwords when chrome://settings/passwords has been loaded, nor does it allow you to export saved account credentials in an unencrypted form (.txt, .json, .csv, etc.) - recent Chrome versions (XP-incompatible, of course) do come with such a feature ... What worked for me to manually transfer account credentials from an old 360EE profile to a new one, on a second, different, machine (from Windows Vista SP2 32-bit to Windows 7 SP1 64-bit) was the NirSoft utility called ChromePass . Depending on the type of your 360EE installation (e.g. "proper" or "portable"), you may have to point ChromePass to the actual 360EE profile dir account credentials are to be extracted from; if you don't have a lot of created site accounts (say, less than 20), then you can manually transfer those accounts to other browser profiles, on the same or different machines... NB: Be sure to first read the CP documentation on its site - for 360EEv13+, Chr86-based, you'd need versions > 1.50 ... Hope I've helped ... Cheers
  16. VistaLover
    Site permissions are stored inside the permissions.sqlite file, inside St52's profile directory; https://support.mozilla.org/en-US/questions/1091830 If you're asking how to modify the "location sharing permission" on a given website, then the article above also covers that scenario: (View) Page Info is also available via the browser's Context Menu ...
  17. VistaLover
    ... I beg to differ : then:
  18. VistaLover
    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) ...
  19. VistaLover
    ... 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 ...
  20. VistaLover
    ... 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 ...
  21. VistaLover
    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 ...
  22. VistaLover
    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
  23. VistaLover
    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 ...
  24. VistaLover
    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:
  25. VistaLover
    ... 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
×
×
  • Create New...