Jump to content

VistaLover

Member
 View Profile  See their activity

  • Posts

    2,307

  • Joined

  • Last visited

  • Days Won

    98

  • Donations

    0.00 USD 

  • Country

    Greece

 Content Type 

Everything posted by VistaLover

  1. VistaLover
    It is currently ca. 00:20 GMT on Mon, Oct 19th and it appears the issue has rectified itself ; "o.rths.ml" is again accessible from my location...
  2. VistaLover
    The Good Old Youtube extension I linked to above has been recently updated to mitigate the broken yt search feature... (screenshot above was taken with New Moon 28; will look slightly different when visiting with Serpent 52 )
  3. VistaLover
    @roytam1 : Has the hostname been changed to something else, again? Can you please share? I am, too, getting the Error 522 Cloudflare response with everything hosted on o.rths.ml ...
  4. VistaLover
    Good Old Youtube also does a brilliant job of re-instating the non-polymer youtube interface (which is more lenient towards computer resources, especially applicable on older hardware/OSes), but, as it is an id-less Web Extension not supported on Serpent 55/52, it doesn't install out-of-the-box ; but if you modify its manifest.json file to include a gecko-id, then it will install (and work) OK! { "name": "Good Old YouTube", "manifest_version": 2, "version": "1.15.0.1-unsigned", "description": "Switch back to classic YouTube interface!", "icons": { "96": "images/logo.svg" }, "background": { "scripts": [ "shared.js", "options/default-options.js", "logger.js", "reconstruct.js", "background.js" ] }, "content_scripts": [ { "matches": [ "https://www.youtube.com/*" ], "css": [ "styles/hide-alert.css" ], "js": [ "shared.js", "content-script.js" ], "run_at": "document_start" } ], "options_ui": { "page": "options/options.html" }, "permissions": [ "https://www.youtube.com/*", "storage", "webRequest", "webRequestBlocking" ], "applications": { "gecko": { "id": "{482060de-6804-4020-a1b9-16dc012a3c93}" } } } (The id string is identical to the one generated when the extension is installed in FirefoxESR 52.9.x)
  5. VistaLover
    https://addons.mozilla.org/en-US/firefox/addon/old-youtube/
  6. VistaLover
    Shadow DOM v1 implementation on UXP is being tracked (by upstream) in https://github.com/MoonchildProductions/UXP/issues/1375 Related implementations tracked in: Custom Elements v1 Google WebComponents ... so the answer to your question is yes... FWIW, are you in any capacity to lend a hand towards implementing the remaining "1/2 of Shadow DOM v1" and/or expediting the full implementation of the rest of the Google-spawned web technologies?
  7. VistaLover
    Isn't this just like Firefox ESR 52.9? It looks as though no-one really pays any attention to the stuff I post ; I mentioned WF Classic just in the previous page... ... And the recent OT discussion about browsers that do NOT launch and run on XP (/Vista) should be better continued in one of the Win7+ subforums... Just my 2 (euro)cents...
  8. VistaLover
    ... Not according to the M.A.T. person, who claims a supreme knowledge of even the "finest letters" of the MPL-2 licence: I think that part was explained previously by M.A.T; hosting the source code of one project covered by MPL-2 in a private repo does not make it Closed Source; whenever the code author releases an executable form (binary) of the code, he has the obligation to provide, by reasonable means, access to the source code that was used to compile the executable form; "reasonable" means could very well be a link to a source tarball or, upon user request, dispatch of the used source via a physical storage medium (the cost of which should be covered by the user requesting it...); what's more important is the fact that the publicly revealed source code does not carry the "buildability" obligation, that is any additional "hack" used by the author to compile the source into an executable form can remain private...
  9. VistaLover
    ! Couldn't agree more on this...
  10. VistaLover
    @Sampei.Nihira : You are, of course, entitled to your own opinion, this is a (mostly) democratic community of users, but as a person whose workflow relies on GitHub (a member since 2014), not installing that linked extension by JustOff means my only other recourse on my current OS (Vista SP2 32-bit without Extended Kernel) would've been (abandoning New Moon 28 and) switching to a 360 Extreme Explorer variant (even v11, Chromium 69 based, was tested to work OK on GitHub)... PS: Let's all hope that upstream get a wake-up call with this recent GitHub debacle and decide to focus on fully implementing Web Components on UXP sooner rather than later... Then we wouldn't have to install workarounds to get GitHub working (at least those of us that need it working...)
  11. VistaLover
    Upstream support forum thread: https://forum.palemoon.org/viewtopic.php?f=70&t=25435 Workaround, that will restore ~ 95% of GitHub's lost functionality: Install github-wc-polyfill-1.0.3.xpi from: https://github.com/JustOff/github-wc-polyfill/releases/tag/1.0.3 All credit goes to (upstream) Ukrainian developer @JustOff ; however, that extension was created with official Pale Moon in mind, hence its install.rdf file has: <em:minVersion>28.14.0</em:minVersion> Should install as is on Mypal 28.14.x (if that's what you want it for ), but to install on latest New Moon 28, one has to edit that line to read: <em:minVersion>28.10.2a1</em:minVersion> The add-on itself has been probably inspired by the WebExtension add-on Polly, that was created for Waterfox Classic users to mitigate GitHub's breakage on Oct 14th 2020... Polly targets a Firefox 56 fork, which has a lot more WebExtension APIs than either Serpent 52.9.0 or Centaury; as a result, Polly will install on Serpent/Centaury, but won't work as designed... Additionally, Waterfox Classic users can (mostly) fix GitHub by toggling dom.webcomponents.enabled to true but, while the same pref does exist in UXP browsers, Web Components support in UXP is extremely unripe/at a very early stage... FYI, github-wc-polyfill extension embeds a base64encoded copy of https://unpkg.com/browse/@webcomponents/webcomponentsjs@2.4.4/webcomponents-bundle.js https://github.com/webcomponents/polyfills/tree/master/packages/webcomponentsjs#using-webcomponents-bundlejs ======================================= Some background: Before the Microsoft buyout () , GitHub would support the latest version of major browsers like Google Chrome, IE/old Microsoft Edge, Safari, Firefox, and care would be taken to not break the current ESR version of Firefox; additionally, "legacy" browsers like Pale Moon, Basilisk, Waterfox (Fx56-based) were "whitelisted" and treated in a special manner so as to remain compatible, but still on a best-effort basis... It well appears that now the "old" team of GitHub developers, the ones sympathetic to "legacy" browsers, have been set aside by the new management, which is hardly any surprise as Microsoft have colluded with evil Google, the net effect being that currently GitHub only caters to the four iterations of Chromium that dominate the browser market (Google's Chromium=Chrome, Microsoft's Chromium=[New] MS Edge, Apple's Chromium=Safari and Mozilla's Chromium-wannabe=Firefox [Quantum] ) ...
  12. VistaLover
    ... Even if the "issue" can be reproduced using official Interlink on a sanctioned Windows OS version and even if the "issue" is acknowledged as a genuine bug by M.A.T. (one person's "unfathomably unacceptable" could very well equate "take it or leave it" in M.A.T.'s universe ) and even if the bug is fixed, the fix will arrive to the reporting user only in binary form, via a future Interlink build release ; i.e., the Binary Outcast source code repository being private, the fix in source code form (commit) won't be public, thus not portable to the fork (Mail News) in a straightforward fashion... @Dylan Cruz: Do you now see the broader picture?
  13. VistaLover
    ...Well, @roytam1 is extremely busy and pressed for time currently in RL, that's probably why the recent discussion about broken YT chat on LIVE streams was not acted upon in a due fashion... Upstream have also received similar reports (be it in the Mac subforum) and Moonchild himself was initially oblivious to the solution: Most thankfully, @rereser stepped in to enlighten the browser guru: https://forum.palemoon.org/viewtopic.php?p=201384#p201384 so I guess that change will soon hit the upstream Pale Moon repo and, hopefully, be merged in next weekend's New Moon 28 builds... NB: As an unofficial/non-endorsed fork, New Moon isn't entitled access to the "Dynamic SSUAO Updates" service, currently put in place for the stable channel of Pale Moon; so, as you said, a NM28 user has to manually correct/modify the YT SSUAO entry inside about:config... OT: Thank you again for notifying "upstream" about this; I guess having an account on both "camps" is useful for cases like this one, where both "worlds" can profit from... But it sure was a prudent thing to exclude even the most minute reference to forks/officially unsupported OSes/MSFN in particular, or a "certain" person will have eaten you raw... (And I've also noticed how that person has adopted a recent habit of checking official forum posters against the database of MSFN members, once a match is found (via username), then the reporter is treated as dirt... ) Kind regards
  14. VistaLover
    Many thanks for still finding the time, between your hectic real life currently, to compile and offer these builds! I think I am one of the very few (possibly the only one?) but I actually read closely and study these official changelogs every week (so rest assured your effort is not in vain...), but I am sorry to say this week's is a sorry mess... And this is identical to last week's: I believe the correct changelog for this week is (what is currently listed under this week's PM changelog): Official UXP changes since my last build: - Issue #1665 - Take overflow-wrap into account when calculating min-content intrinsic size. (8e18743ab) - Issue #1666 - Implement overflow-wrap: anywhere (dadef50bd) - [devtools] Teach devtools about overflow-wrap: anywhere (521f2b476) - Issue #1606 - Add support for multi-monitor DPI awareness v2 (W10 1706+) (bda6f1a93) source: https://github.com/MoonchildProductions/UXP/commits/master Correct changelog for this week is: Official Pale-Moon changes since my last build: - Back-end branch pointer update (Unstable 2020-10-04) (f6ae5e0) - [app update] Move update cert entries to branding (b48aee5) - Issue #1812 - Enable per-monitor DPI v2 in Pale Moon (762408f) - [SSUAO] Update Yahoo override, since they now throw a fit when seeing anything "Pale Moon" in the UA. (aa3ff77) source: https://github.com/MoonchildProductions/Pale-Moon/commits/master NB: http://rtfreesoft.blogspot.com/2020/10/weekly-browser-binaries-20201010.html is also messed up!... Take the best of care!
  15. VistaLover
    Let us hope the official UXP/Basilisk repositories remain public, so that any future purging of 32-bit-only codeblocks could be reverted... Nonetheless, successfully compiling the source for x86 targets will turn, over time, into an increasing challenge, since upstream won't test anymore whether their codebase compiles into 32-bit binaries, nor would they offer any kind of help to mitigate eventual future 32-bit compilation errors...
  16. VistaLover
    @Alex654 : I just navigated to a LIVE youtube stream: https://www.youtube.com/watch?v=DDU-rZs-Ic4 with the very latest New Moon 28 32-bit build (buidID=20201002092931) and live chat is displayed correctly: My yt SSUAO currently is general.useragent.override.youtube.com;Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) I can confirm that by restoring the default yt SSUAO: general.useragent.override.youtube.com;Mozilla/5.0 (%OS_SLICE% rv:60.0) Gecko/20100101 Firefox/60.0 PaleMoon/28.10.2a1 "Live Chat" BREAKS, as you reported:
  17. VistaLover
    This is a known issue that has already been reported in the "upstream" support forum, as it is reproducible in official Pale Moon client (v28.1x.x): https://forum.palemoon.org/viewtopic.php?f=70&t=25154&p=198725 Last post from OP (a month ago) suggests a youtube.com SSUAO mimicking a Fx 62.0+Basilisk UA, e.g. Mozilla/5.0 (Windows NT 6.1; rv:62.0) Gecko/20100101 Firefox/62.0 Basilisk/52.9.2020.10.05 fixed things for him at the time... NB: Just a friendly reminder , when you seek help for an issue affecting specific sites/services, be kind enough to also provide clear URLs where the issue reported can be tested by other members of this community who may not be familiar with the issue at hand (FWIW, I don't have a Google/YouTube account and I NEVER use the "chat" feature ) ... Best greetings
  18. VistaLover
    Hello there @feodor2 That code was probably ported from Arctic-Fox, a Tycho (Pale Moon 27's platform) fork targeting mainly old Macs: Part1: https://github.com/wicknix/Arctic-Fox/commit/9e6e13a15ae60fc4379b9dd0dd26969784b13a53 Part2: https://github.com/wicknix/Arctic-Fox/commit/bc40f1eb67037a878c0b270f72efb3076cfcf01e That code there affects only FFmpeg's h264 decoder but, by the looks of it, is turned OFF by default; you'd have to create the hidden about:config boolean pref: media.ffmpeg.skip_loop_filter and set it to true to make use of it... I can't speak from experience, because under Vista SP2 32-bit I'm not seeing (rather... hearing ! ) this bug ; but having followed closely related discussions in the past, I can surmise that: Twitter don't care at all for a Pale Moon user-agent (or any other non-mainstream browser they don't support ), so they are treating it as a generic mobile device browser, thus feeding it with a lower quality/bandwidth audio stream encoded in the HE-AAC (v1/v2) profile (more here); most times, they stream using either AppleHLS and/or MPEG-DASH (i.e. fragmented streams), rather than progressive download streams; the ffvpx library patch (to contain additional h.264/aac decoding support) is just a hack to cater to Windows XP's lack of Windows Media Foundation (WMF), i.e. native patented decoders; it hasn't been identified, yet , where exactly things break, but the patched ffvpx can't cope fully with HE-AAC over fragmented (aka adaptive bitrate ) streams, hence the audio distortion under XP (NB: On Vista+, NM28 makes use of WMF decoders [media.wmf.enabled;true] and this issue does not manifest itself... ). Switching to Firefox compatibility UA-mode (or using a Firefox SSUAO for twitter.com) allows Twitter to treat NM28 as a desktop browser and thus it is fed audio in the higher quality/bandwidth AAC-LC format (and possibly via progressive HTTP streams) that ffvpx can decode more efficiently... But YMMV, especially between various sites... Kind regards
  19. VistaLover
    My extensive tests contradict your reports! Using the very latest New Moon 28 package (32-bit on Vista SP2 x86) with a pristine NEW browser profile, and the "lazy-loaded" images of products (sport-shoes in your linked example) DO LOAD eventually, fully: and on a selected item's subpage: Proof of used browser: ... So, it is my educated guess that something on your side is breaking things I would first check with a new clean NM28 profile (like I did myself), and if you can't reproduce, then there's something in your customised profile (user-set prefs, extension-related changes, etc...) that causes this brekage... I would start with privacy related about:config settings and/or content blocking extensions (ad/script blockers, etc...) If, however, you can reproduce in a clean profile, then the culprit is system-wide (but you saying you can view the images with Serpent 52 pretty much rules that out...)... FWIW, the images are loaded from "*.rozetka.ua" domains, over HTTPS (TLS 1.2 in my case), e.g. https://i8.rozetka.ua/goods/17624553/puma_4062451528768_images_17624553343.jpg
  20. VistaLover
    Could you explain what this means? Is this a v28-only build preference Please read below: that's the accessibility libraries, official builds and my old builds used to have --disable-accessibility specified. I lost the build config and then it turns on that on compilation. ... and will go if I remember to do this. As to: I'm not currently using NM27, but do you now (i.e. in latest builds) see extraneous accessibility files inside its main directory? FWIW, one can always consult built-in pages like "about:buildconfig" to read build-time configuration flags...
  21. VistaLover
    Moonchild's stance is now "if the mountain won't come to Muhammad, then Muhammad must go to the mountain", as expressed (along with "name calling") below: https://forum.palemoon.org/viewtopic.php?p=200402#p200402 and further down in that thread:
  22. VistaLover
    Likewise on Vista SP2 32-bit :
  23. VistaLover
    With respect. this fact alone doesn't tell "us" anything useful, i.e. it doesn't contribute in the slightest towards identifying the exact cause of the issue reported in recent New Moon 28/Serpent 52 builds affecting you and several others... .... And, despite me having posted about it numerous times in the past, the Mypal fork is based on the release (stable) upstream branches of UXP+Pale Moon, while NM28 is based on the master (unstable) branches of UXP+Pale Moon (i.e. newer code; don't just let appVersion numbers fool you; arithmetic may dictate 28.13.1 > 28.10.2a1, but it's not the case code-wise); if that "bug" (probably connected to specific hardware setups and/or use of certain extensions) doesn't bite you yet in Mypal 28.13.1, it might when you later upgrade to Mypal 28.14.0 or later... IOW, switching to Mypal 28.13.1 from recent NM28 builds might be akin to @sal here downgrading his St52 copy to older buildID=20200904161558 What is unfortunate though is that our maintainer can't replicate it (yet?), so things for now look grim...
  24. VistaLover
    Thanks for building this time with the " --disable-accessibility" flag... I had commented: Upon testing, it appears that the latest Serpent 52.9.0 (32-bit) (BuildID=20200925161000) remains unaffected by that bug, which is, hence, only manifested in latest New Moon 28.10.2a1 (32-bit) (BuildID=20200925153118); but my initial assessment was correct - upstream commit https://github.com/MoonchildProductions/Pale-Moon/commit/9f56811e04ef4703aec82ba6a7c712e50c7667c0 was indeed the one that broke the native downloads manager... Moonchild became aware and later authored: [downloads] Correct and simplify host handling. https://github.com/MoonchildProductions/Pale-Moon/commit/fd30b23a0dfa2373539b348519aa9864976b46dd ... but, alas, it came too late for "us" , that one was not included in https://github.com/roytam1/UXP/commits/custom when latest NM28 was compiled... I have confirmed that the "fix" works as intended, restoring the functionality of the native NM28 Downloads Manager, as well as the functionality of the (legacy) Downloads Window extension several users (including yours truly ) have installed... I understand, your spare time allowing , that the fix will be included in next Saturday's released builds, in the interim I have taken the liberty of modifying and uploading a patched omni.ja file latest NM28 users could download to regain lost functionality: omni.ja https://www119.zippyshare.com/v/lAv8DFrY/file.html It should be placed inside "./palemoon/browser/" overwriting original omni.ja file (or you could rename/back-it-up first, e.g. as omni.ja.BAD) ; hope I've helped!
  25. VistaLover
    uB0-legacy now targets at least a Mozilla 45 compatible platform, so it remains compatible with FxESR 45, UXP-based browsers (NM28, Serpent 52.9.0), as well as Serpent 55.0/Moebius, but compatibility with Tycho-based browsers (NM27) is, sadly, lost... The very last stable version that is compatible with NM27 is 1.16.4.21 : https://github.com/gorhill/uBlock-for-firefox-legacy/releases/tag/firefox-legacy-1.16.4.21 I prefer myself uB0 to the AdBlock Plus family of content blockers (not least because the latter consume far more RAM), but it is true that v1.16.4.21 will remain onwards in an unmaintained state, while, OTOH, several useful filter lists now target recent versions of content blockers and, as such, employ more recent code formats/syntax that, unfortunately, the combination of NM27+uB0-1.16.4.21 can't cope with any more... So expect, over time, uB0-1.16.4.21 to become less efficient in its designated blocking tasks... I don't use myself NM27 quite often, but when I do (and for the specific sites I visit with it), uB0-1.16.4.21 serves me well for the time being...
×
×
  • Create New...