Jump to content
MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. ×

VistaLover

Member
  • Content Count

    965
  • Joined

  • Last visited

  • Days Won

    60
  • Donations

    $0.00 

VistaLover last won the day on February 4

VistaLover had the most liked content!

Community Reputation

971 Excellent

About VistaLover

Profile Information

  • OS
    Vista Home Premium x86
  • Country Flag GR

Recent Profile Visitors

4,723 profile views
  1. @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 itsel
  2. 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
  3. 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 Goog
  4. <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>
  5. @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
  6. 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).
  7. 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...
  8. 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...
  9. 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 Java
  10. 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 Cl
  11. ... 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
  12. 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 e
  13. Sadly , all four links above produce a 404 Not Found server response currently (ca. 00:00 UTC 20/02/2021) ...
  14. ... 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 w
  15. Posted about it previously in https://msfn.org/board/topic/180462-my-browser-builds-part-2/?do=findComment&comment=1195339 You can download videos and images from selected sites only, namely: These are local downloads, no on-line service is being used (i.e. you fetch straight from yt servers) ... MPEG-DASH streams also supported, either via downloading separate V+A streams and then manually merging them into a compatible container via your local copy of FFmpeg, or via an experimental alpha feature, where the merge is managed by the script itself... Since pra
×
×
  • Create New...