Jump to content

VistaLover

Member
 View Profile  See their activity

  • Posts

    2,109

  • Joined

  • Last visited

  • Days Won

    93

  • Donations

    0.00 USD 

  • Country

    Greece

 Content Type 

Everything posted by VistaLover

  1. VistaLover
    <OT> .... well, one related thread I did not manage to dig up in time... https://msfn.org/board/topic/181267-chromium-v-54-not-displaying-youtube-properly/ </OT>
  2. VistaLover
    <OT> Official link from author: http://browser.taokaizen.com/download/Advanced_Chrome_Windows_v54.20.6530.0.zip I'm out of breath in these forums saying that, in reality, Advanced Chrome v54 is NOT actually Chromium 54, but more of Chromium 48 under the hood... The percentage of Ch54 in it is quite small (just like Serpent 55 is actually, originally, a fork of Firefox 53.0a1, not Firefox 55.0!) ... Also, from https://browser.taokaizen.com/ 05 - Jan - 2018 .- Updated Custom Build to 54.20.6530.0 New on version 54.20.6530.0: Crash bug fix. Removed dynamic user agent, you can install Chrome UA Spoofer extension to change it. Not vulnerable versus Meltdown and Spectre. ... meaning that AdvChr54 advertises itself to YT as Ch54, not Ch48/49, and is thus being served incompatible polymers... I have an existing old installation of User-Agent Switcher for Chrome v1.1.0, by setting up a new custom UA of Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36 naming it Chrome 49 [C49] and using that as a general UAO, yt then loads (after a wait of 10 - 20s, that is...) : However, if you haven't installed said extension in the past, you're just out of luck: Evil Google have recently (2021-01-19) re-uploaded it on CWS as a CRX3 only package, meaning it won't install now (you can try the archived file on https://www.crx4chrome.com/crx/515/ ). If the XP people want a current-ish Chromium engine, please use the Chinese-made, Russian re-packed, versions of 360 Extreme Explorer 11/12/13 (see relevant XP forum threads) ... </OT>
  3. VistaLover
    <OT> According to https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=49&platform=XP SP3 Google Chrome 49 under fully updated XP SP3 should support the TLSv1.2 protocol, BUT with a limited number of cipher suites; supporting the protocol natively is one thing, but supporting ciphers to go with it is another ; Chrome 49 relies on OS crypto libraries for ciphers and the OS cert store for root certificates; XP doesn't support ECC suites and SNI, these two handicaps limit even more the amount of HTTPS sites that can be accessed... PS: Just compare the record of Ch49/XPSP3 (above) to Ch49/Win7 (below): https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=49&platform=Win 7 </OT>
  4. VistaLover
    I tried to reproduce with latest NM27 v27.10.0 (32-bit) (2021-03-05) here (Vista SP2 32-bit) and I couldn't; everything works fine in that regard ... Unless this bug is selectively targeting XP, in your case I would troubleshoot further by checking in a new pristine NM27 profile; chances are one of your installed extensions broke in builds past the 2020-11-28 one, manifesting the issue... <OT> Hint: ... all versions/flavours of Opera past v36 require Windows 7 SP1 and higher (portable v37 can also launch under Vista SP2, but not on XP SP3). Opera 36 is also based on a Chromium 49 core/engine; I hadn't launched my portable copy of Op36 in ages, but. by the looks of it, it manages to open/render Youtube fine: However, under XP, Opera (unlike Google Chrome 49) can't use patented decoders (h264, aka avc1, and aac), so only the other HTML5 codecs (vp8/vp9/opus/vorbis) can be used, possibly taxing resources and causing playback skips... </OT>
  5. VistaLover
    Also confirmed in latest Serpent 52.9.0 (2021-03-05) (32-bit) under Vista SP2 x86; a UA of Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Goanna/4.8 Firefox/52.0 Basilisk/52.9.0 will load/redirect to: https://www.opera.com/ie-simple while Mozilla/5.0 (Windows NT 6.3; rv:78.0) Gecko/20100101 Firefox/78.0 will load the full-blown, mobile design iteration of their homepage... (just https://www.opera.com/ ) The OS fragment of the UA is also at play here; with the first UA I get offered the XP/Vista EOL Opera version (36.0.2130.80 - offline installer) when I hit the "Download now" button, while with the second UA I'm offered an online (stub) installer of Opera 74.0.3911.203 (requires Win7+). Lastly, with Mozilla/5.0 (Windows NT 6.0; rv:78.0) Gecko/20100101 Firefox/78.0 I do load the full edition of the Opera homepage, but upon clicking the "Download now" button, I'm being redirected to https://www.opera.com/ie-simple and hence towards the offer of Opera 36 ... OT: Opera 36.0.2130.80 dates back to August 2016 (!); is anyone among you (still) using it? And if yes, how does it cope with the 2021 web (the one Google single-handedly have created) ?
  6. VistaLover
    Hi @Vistapocalypse , sure hope you're OK under these perilous times... I'm kinda lazy now to dig up my portable copy of YB 17.4 (Chromium 57 based), so I'll assume that whatever is true for portable YB 17.6 (Chromium 58 based; launches on Vista SP2 but NOT on XP SP3) stands also true for the former... One must disregard the blatant banners and incompatibility messages displayed when visiting the OWS with YB 17.x; according to https://forums.opera.com/post/208773 ... it is probable that versions of YB > 20.3.1.197 won't install Opera extensions anymore; but this is certainly not the case for YB 17.6! Just persevere with the "Install Extension" button and Bob's your uncle: I hope those pics dispel whatever latent doubts...
  7. VistaLover
    ... And the rift between @JustOff and his ex-associates within MCP grows wider and wider... ; the screengrab below is from NM27's add-ons manager (AOM): Thank you JustOff for standing up against authoritarian oppression...
  8. VistaLover
    Which version of Yandex Browser is this happening on? The XP/Vista compatible version (17.4.1.1026) is not able anymore to install newer signed Chrome extensions (.crx files) from the CWS or elsewhere, because, since last May 2020, those are only being packaged in the newer format CRX3, which requires a more recent (to 57) Chromium core... YB 17.4 only supports the older CRX2 format, so in a new profile you can only install compatible extensions which were last updated before May 2020 - in an existing profile, previously installed extensions won't auto-update to a new version, if that has been released after May 2020; also, be careful not to inadvertently uninstall existing extension(s), CWS (unlike AMO) doesn't keep older versions of extensions, thus you may find yourself in a position of not being able to re-install said extension(s) ... YB has native support for Opera extensions, so you may try installing uBlock Origin from the Opera Web Store: https://addons.opera.com/en/extensions/details/ublock/ BTW, YB comes already bundled with its own content blocker, AdGuard Adblocker, the last version compatible with 17.4 is 3.5.23 ... PS: There's enough info on-line covering the differences between CRX2-CRX3 packaging formats, just use your favourite search engine...
  9. VistaLover
    Did you take care to also restart the machine between uninstallation of 14.28.29812.0 and installation of 14.28.29213.0 ? Firefox specifically comes with a dependentlibs.list file inside its main appDir, whose content reads: MSVCP140.dll api-ms-win-crt-runtime-l1-1-0.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-heap-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-convert-l1-1-0.dll VCRUNTIME140.dll api-ms-win-crt-math-l1-1-0.dll api-ms-win-crt-filesystem-l1-1-0.dll api-ms-win-crt-environment-l1-1-0.dll mozglue.dll api-ms-win-crt-utility-l1-1-0.dll api-ms-win-crt-time-l1-1-0.dll api-ms-win-crt-multibyte-l1-1-0.dll nss3.dll lgpllibs.dll api-ms-win-crt-locale-l1-1-0.dll xul.dll So, firefox.exe is instructed to forcibly look for these DLLs (12 api-ms-win-crt-*.dll that are part of Windows 10 Universal C Runtime, 2 that are part of VC++2015-2019, 4 that are part of Firefox itself) only there, not in system directories... If you remove just the Win10UCRT dlls without also removing them from inside dependentlibs.list, then you'll get the "Can't load XPCOM" launch error... For Vista SP2 and higher, we have KB2999226 (Win10UCRT), so if I modify dependentlibs.list to MSVCP140.dll VCRUNTIME140.dll mozglue.dll nss3.dll lgpllibs.dll xul.dll ... I can launch Firefox without any api-* DLLs present adjacent to it (they are loaded from within system32); likewise, trimming down dependentlibs.list to just: mozglue.dll nss3.dll lgpllibs.dll xul.dll will force firefox.exe to look for dependent DLLs (Win10UCRT + VC++) in the system dirs, if they're absent in appDir; if you don't have them installed either, then you'll get the following launch error: Because KB2999226 doesn't exist for XP, VC_redist.x86.exe does bundle/install these Win10UCRT DLLs under XP... Are things any clearer now?
  10. VistaLover
    ... Does that test imply first deleting the copies of MSVCP140.dll & VCRUNTIME140.dll (v14.0.24210.0) that were originally shipped with FxESR 52? Yes: https://docs.microsoft.com/en-us/windows/win32/api/threadpoolapiset/nf-threadpoolapiset-closethreadpoolwork#requirements
  11. VistaLover
    ... Yes, this fact was posted already on Feb 6th by @George King , so nothing revolutionary here (no disrespect meant) ... As you belatedly found out, I posted these already on Feb 6th, but I guess having the last post on a thread's page is a safe bet others will miss noticing it... OT, of course, for this thread, but 14.28.29812.0 installs and runs perfectly fine under Vista SP2 32-bit (CPython 3.7.10 x86 launches fine with it, doesn't launch without it! ) Kind regards
  12. VistaLover
    @Sampei.Nihirahas only been using New Moon 28; in his reply, he's not saying anything about Serpent 52; once again, the usual confusion between platform (UXP) and applications (NM28 vs St52) built on top of that same platform (i.e., the common platform does not exclude the existence of differences between the applications...) ... A simple test in Firefox ESR 52.9.1 reveals that privacy.firstparty.isolate;false indeed exists already in it, so it's no wonder it's there too in its direct descendant, Serpent 52.9.0 ... A cursory search in Bugzilla reveals that the pref itself was first implemented as part of #1260931 : [Bug 1260931 - Part 2: add pref privacy.firstparty.isolate] https://hg.mozilla.org/mozilla-central/rev/d173cefba1e1 in Firefox 51.0a1; but to give credit to Sampei , the feature behind that pref seems to have matured in Fx 55.0 stable, and this is where many Google search results agree on: https://www.bleepingcomputer.com/news/software/another-tor-browser-feature-makes-it-into-firefox-first-party-isolation/ https://www.ghacks.net/2017/11/22/how-to-enable-first-party-isolation-in-firefox/ TL;DR privacy.firstparty.isolate does not exist in NM28, but does exist in St52 (default=false); toggling that pref in St52 (to true) presents risks that (some) sites may break, because First Party Isolation in FxESR 52 was in its infancy development-wise... Addendum: privacy.userContext.ui.enabled likewise is absent in NM28, but present in St52; I'll leave it as an exercise to the reader to track down when that pref was first introduced in Firefox (and thus ended up in St52) ... Hint: it's related to Container Tabs, a feature originally present in FxESR 52 and official Basilisk 52, which the MCP devs later decided to scrap ; due to demand by members here, again expressed more loudly by MIA @Mathwiz , that feature still survives in Serpent 52.9.0...
  13. VistaLover
    Pale Moon as an application had never incorporated any WE support whatsoever, and that was, of course, true for v27, which was Tycho (Mozilla ESR 38 fork) based; when MCP "transplanted" the Pale Moon application onto their new UXP platform (Mozilla ESR 52 fork) and upgraded its major version from 27 to 28 (and, recently, to 29), no provision was made to equip it with any means of accessing the WE code then present in the new platform; Pale Moon shall forever stay free of the Web Extension "pollution"... In its initial days, Basilisk was touted as the browser non-Quantum Fx migrants should choose, because, unlike Pale Moon, it supported both "legacy" and WE addons, plus it had EME (WidevineCDM) support; where are we now? WE support removed, EME support broken, soon to be completely excised... IOW, Basilisk is practically Pale Moon wearing the Australis interface (oversimplified, differences do exist...).
  14. VistaLover
    The original Basilisk 52 project from "upstream" did have WE support, be it somewhat inferior to the one present in the Mozilla 52.6.0 platform they forked off as UXP; the MCP devs disabled/removed some WE features/APIs initially, e.g. id-less WEs were not supported, because Basilisk 52 does not observe extension-signing... Having partial WE support in their test UXP browser application (Basilisk) was something the MCP people felt quite uneasy about, given their lack of any will to further maintain that part of the platform code; coupled with their general disdain/aversion for WE (a Google Chrome spawned and Firefox-aped technology), they finally removed completely all traces of WE support in Basilisk 52 in February 2019 (Basilisk-52.9.2018.12.18 the last with WE support, Basilisk-52.9.2019.02.11 the first with no WE support). After consultation with members here (where are you @Mathwiz ? ) it was decided that Serpent 52 will continue to contain that (partial) WE support in an "unmaintained/use at your own risk" state ; WE related security issues are not being patched by upstream/our current maintainer; if you install from AMO, be warned that many (WE) addons there are marked in a blanket fashion as "working in Fx 48.0 and higher", but often times this is simply not true, because WEs of today are NOT being tested on Fx 48-52 ; additionally, Serpent 52 does not check AMO for WE updates, so that is left upon you (i.e. bookmark a WE addon's page on AMO and visit occasionally for eventual updates); be weary of WE updates, in many cases the updated addon uses WE APIs not present in St52... I personally use several WEs in St52, e.g. the userscript manager Violentmonkey 2.12.9 and userstyle manager Stylus 1.4.23
  15. VistaLover
    <OT> @Sampei.Nihira : May God rest his soul and forgive all of his sins... As we say here in Greece, I wish him a "good paradise" ... </OT>
  16. VistaLover
    @exogenesis, @roytam1 https://bugzilla.mozilla.org/show_bug.cgi?id=335545 https://bugzilla.mozilla.org/show_bug.cgi?id=335545#c14 https://forums.linuxmint.com/viewtopic.php?t=208270 Google searches also implicate browser extensions... clipboardcache files are also created by your OS's clipboard manager, when you copy to the clipboard content exceeding some minimum size: http://jonathan.lalou.free.fr/?p=121 If you want absolute privacy, don't copy/paste login credentials in your browser, type them instead directly (unless, of course, you've been infected with keyloggers ) ... FWIW, #335545 was "resolved" in Fx 60 ...
  17. VistaLover
    Profiles of Serpent 52.9.0 are basically architecture independent, except if you have extensions with binary components (very few exist), plus you'll need the x64 versions of some plugins (e.g JRE) if you want them to load in a x64 browser profile... However, I can't currently test with a x64 OS, so take what I said with a very minute (!) pinch of salt... As you noted, mixing profiles of different applications isn't advised - and profile migrations within the same application should only be attempted when updating from an older to a newer application version/build (i.e. not backwards).
  18. VistaLover
    Thanks for the clarification and screengrab ; so, the AOM will definitely look as "before", but not act completely as "before" ; I browsed briefly the changes inside extensions.js & extensions.xul, what I gathered (at this early morning hour here) - and is proven correct by your image - is that we'll have both the "fixed" version number (as before) and the version number as a tooltip (conceived by Mozilla to replace completely the former ), when cursor placed inside the extension's entry...
  19. VistaLover
    I think I fixed this with "add_ons_manager_version_number-1.0.2-nm27.xpi" : It'll have to do until next week's NM27 build is released...
  20. VistaLover
    https://github.com/roytam1/palemoon27/commit/3bb6519 Hugely indebted ; if I might ask, what exact part of #1161183 was not reverted? IOW, will NM27's TychoAM look the same as in previous build 27.9.7 (32-bit) (2021-02-12) ? Using Aris' extension [Add-ons Manager - Version Number v1.0.1] in latest NM27 isn't a complete solution, because while it does restore version numbers, it takes away the "blue/red dot" feature of TychoAM; I guess this is because said extension uses files from Fx 40.0, not PM27... Thanks for that ; I wasn't sure if that was the case (... I don't speak Javascript , remember?), plus I was feeling lazy to test in Fx < 41.0, so to be on the safe side I hardcoded <em:minVersion>41.0</em:minVersion>, with the expectation that Fx < 41.0 users could always continue using v2.1.9 of the extension... Best regards
  21. VistaLover
    Another not welcome (at least by me) implemented change in latest NM 27.9.7 (32-bit) (2021-02-19), as a result of backporting Fx 41.0 code, is the disappearance of extensions' version numbers inside addons-manager (AOM): This is a direct result of Bugzilla Bug #1161183 landing in https://github.com/roytam1/palemoon27/commit/fd2bb43 as: Bug 1161183: Don't show the add-on version in the list view. r=dao (559bfa7a5) That change was one I objected to with vigor at the time (being a Nightly Tester), but when Firefox 41 stable arrived with it merged, I was already using Classic Theme Restorer, which soon provided a setting to restore AOM to the way it was pre-41... Of course, other Firefox users complained to Mozilla about this change, but Mozilla by then were already on a steady course to degrade their browser into one targeting 10yr-olds, so, unfortunately, Bugzilla Bug #1175324 was WONTFIXed I don't know how @roytam1 feels about this change, but Aris is here again to the rescue: caa:addon/amversionnumber/versions?page=1#version-1.0.1 Download the very first version (1.0.1) of "Add-ons Manager - Version Number", patch install.rdf to add a NM27 specific targetApplication block (see my previous post) and install:
  22. VistaLover
    ... and here is AdblockEdge v2.1.10 for NM27: http://s000.tinyupload.com/?file_id=00091647840675622436 Changes from v2.1.9: 1. Implemented patch to ui.js as per @roytam1 2. Removed signature related directory/file 3. Removed references inside chrome.manifest to non-existing localisation dirs 4. Cosmetic changes to install.rdf 5. Changed Fx related entries inside install.rdf to <em:minVersion>41.0</em:minVersion> <em:maxVersion>45.*</em:maxVersion> ... so it could install and work in FxESR 45 fork (hopefully...) 6. Introduced NM27 targetApplication block inside install.rdf, so it could install as a native extension: <em:targetApplication> <Description> <!-- New Moon 27.9.7+ --> <em:id>{8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}</em:id> <em:minVersion>27.9.7</em:minVersion> <em:maxVersion>27.*</em:maxVersion> </Description> </em:targetApplication> 7. Removed fennec2+seamonkey+thunderbird targetApplication blocks... 8. Changed homepageURL to the last working webarchive snapshot: http://web.archive.org/web/20180516130655/https://bitbucket.org/adstomper/adblockedge DISCLAIMER: Use at your own risk - not tested extensively; as I said already, users of 2.1.9 should probably move on to a more current/maintained adblocker extension...
  23. VistaLover
    Adblock Edge v2.1.9 was the last version released before being discontinued and removed from AMO: https://dwaves.org/2017/03/01/why-was-adblock-edge-firefox-addon-removed-from-mozilla-extensions-repository/ It only ever supported Fx 26.0-39.0 to begin with... If NM27's current "upstream" are implementing Fx 41.0 code, then more breakage will take place, not only restricted to this one, but possibly with other extensions originally supporting/designed for Mozilla 38.0, which is what the original Tycho (in NM27) was forked off... @bernd will probably have to change his adblocker extension altogether... Can you try https://addons.palemoon.org/addon/adblock-latitude/ or https://addons.palemoon.org/addon/abprime/ ?
  24. VistaLover
    Sadly , all four links above produce a 404 Not Found server response currently (ca. 00:00 UTC 20/02/2021) ...
  25. VistaLover
    ... Does it work on NM27? It would be unfair to compare browser extensions and/or userscripts to standalone CLI/GUI dedicated downloaders, wouldn't it? I, for one, have been an avid user/proponent of the original yt-dl CLI app, and have recommended it before in these threads without reservations (and it's an added bonus for XP users that it still supports the OS, because the devs build the Windows binary on py3.4.4)... I'm also fully aware of the existence of the yt-dl forks, yt-dlc (now abandoned) and yt-dlp (formerly/briefly yt-dld - fork of yt-dlc), that became prominent when (USA based) RIAA issued a DMCA takedown against yt-dl on GitHub... I currently use either one of yt-dl/yt-dlp (the latter has some teething issues still. also some quirks I'm not yet familiar with), for Live streams I also use streamlink (officially supported only on Win7+, but with some custom fixes (py3.7) would also run under Vista SP2 - no XP support at all is currently possible ). I'm also fully aware - the XP and Vista 32-bit communities owe a great debt to @Reino (previously aka @CoRoNe) for his 32-bit builds - especially now that the Zeranoe repos/forums have vanished into thin air and the other Windows-binary providers are ONLY compiling/offering 64-bit ffmpeg builds... Kind regards
×
×
  • Create New...