Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

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. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


roytam1

My build of New Moon (temp. name) a.k.a. Pale Moon fork targetting XP

Recommended Posts

Personally, I'm not at all content :angry: with the decisions made by the Moonchild+Tobin duo... 

In New Moon 28, I am, of course, confined to only using "legacy" extensions, many of them I inherited from my FxESR 52 usage era; they (continue) to work at this time of writing but the harsh truth is when they start to break (and they will, sooner rather than later -_-), the chance they receive proper bug fixes, especially those that started life in AMO and haven't been forked to APMO (GitHub?), is minute/none... :angry:

Recent "troublefests" in NM28 for me include Print Edit 18.4 (a rather convoluted, hack-ish, method to regain basic functionality is to be found in the Pale Moon forums, since the original developer shows no interest at all in fixing his XUL version: all development efforts are focused on its WE counterpart) and Stylem 2.2.4, which is currently bugged and unable to follow the progress made in the UserStyles field; more specifically, it is unable to correctly install configurable userscripts from "UserStyles.org" and has 0 support for the new "trend" that is the "user.css" format (to which many style authors have already changed :( ...).

Even Moonchild himself acknowledges that there is a dim future regarding author support for XUL extensions (intended for consumption by PM/Basilisk users):

https://forum.palemoon.org/viewtopic.php?f=46&t=21214

As @Mathwiz has already pointed out, in Serpent 52.9.0  I had found an elegant way to keep on using the greater part of the WEs I was using in FxESR 52; some of these WEs have progressed to versions incompatible with FxESR 52 and/or UXP, so am again forced to using slightly older versions (with no hope of receiving further updates), some others continue to be routinely updated to fix newly introduced bugs; plus, there's always a chance I can find on AMO a new (to me) WE (that I wasn't necessarily using in FxESR 52); in any case, retaining that (rudimentary, at times) WE support in Basilisk/Serpent was always welcome :) by me,,, 

For example, I can install and use Stylus 1.4.23 (WE-only) in Serpent 52.9.0, alongside Stylem 2.2.4, to properly install configurable userstyles and "user.css" type styles from GitHub (and elsewhere). And while Moonchild claims: 

Quote

XUL extensions already offer anything WEs can do, and then some,

in every day practice that statement is far from being a Holly Truth :angry:; there exist (recent) extensions that only started life in the WE format; as a non-coder, it is impossible for me to "translate" them to the superior XUL format and satisfy Moonchild's expectations...

I have quite a few WEs installed in Serpent 52.9.0, these include

Google search link fix 1.6.7
ImTranslator:  14.15 (last version properly working)
Markdown Viewer Webext 1.4.0
Native MPEG-Dash + HLS Playback 1.1.0 (only available as WE)
Play/Pause 2.0.3
uBlock Origin 1.17.7.102
View Page Archive & Cache 1.5.3
Violentmonkey 2.10.1 (only available as WE)
Adaptive Bitrate Manifest Viewer 0.9.0 (only available as WE)
Browsec VPN - Free and Unlimited VPN 3.16.16 (only available as WE)
SaveFrom.net helper 8.1 (only available as WE)
Stylus 1.4.23 (only available as WE)

... so I'll be quite frustrated :realmad: when Basilisk (Serpent) 52

Quote

will very likely automatically remove all installed WebExtensions from your browser profile since they will become invalid extensions.

In any case, I might keep a copy of the last WE-compatible version of Serpent 52.9.0, use my copy of Serpent 55.0.0 (which, incidentally, has better WE support) or some other thing...

BTW, reddit, ghacks and the like are mostly infested by Mozilla fanbois, who never lose breath badmouthing all Firefox forks (including Pale Moon, Basilisk, Waterfox), so I never place credence to all the FUD they're spreading there... Yes, I am to an extent concerned with browser security, but usability is of primary importance to me...

10 hours ago, roytam1 said:

Waterfox team may try to keep them coexist as long as possible

Being on 32-bit Vista, this obviously holds little promise for me... Unless you're implying the Waterfox Team efforts would, somehow, find their way into your forked UXP copy (hence Serpent 52.9.0)... ;):whistle:

Edited by VistaLover
Improved English language used, additional formatting
  • Like 1
  • Upvote 1

Share this post


Link to post
Share on other sites

6 hours ago, Mathwiz said:

Thanks.

I have UBO. The WebRTC checkbox on my UBO settings page is greyed out; possibly because I installed the WebRTC add-on (via @VistaLover's suggested mods) for testing.

Really, the only advantage of a dedicated add-on is that you can toggle your internal IP address on or off with one click. Otherwise, you have to go into UBO, open the dashboard, click settings, and click the checkbox. Or you have to go into about:config, filter, and toggle the media.peerconnection.enabled setting. I would think either is too much trouble for folks that actually use WebRTC.

Actually is because the ublock origin you have installed is a  later version and not the legacy one ( 1.16.4.7 ) that is why is greyed out.

  • Upvote 1

Share this post


Link to post
Share on other sites
On 1/21/2019 at 6:57 PM, Tangy said:

@Mathwiz  You may do so through ublock origin

@Tangy: You appear to have this setting checked (Prevent WebRTC from leaking local IP addresses) while using New Moon; in all honesty, I don't think it has any bearing on New (Pale) Moon, since WebRTC is disabled there at code level...  But it's certainly applicable on FirefoxESR 52.9.0, Serpent 52.9.0 and even Serpent 55.0.0; the wiki link for that feature, for anyone concerned, is: 

https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-leaking-local-IP-address

On 1/21/2019 at 8:34 PM, Mathwiz said:

I have UBO. The WebRTC checkbox on my UBO settings page is greyed out; possibly because I installed the WebRTC add-on

According to tests I performed on both FirefoxESR 52.9.0 and Serpent 52.9.0, this issue you report appears to manifest itself exclusively with the WebExtension version of UBlock Origin ; if one installs the XUL version of uB0, currently at version 1.16.4.7, then the checkbox remains "clickable" no matter the value of boolean pref "media.peerconnection.enabled"; switch to the WE version of uBO (stable channel currently at version 1.17.4) and one discovers that the WebRTC checkbox has been disabled (and text greyed out :angry:), again irrespective of the state of the "media.peerconnection.enabled" boolean pref...

*******************************************************************

A word to those using uB0 WE on Basilisk/Serpent 52.9.0 :

1.17.4 is the final version that can be installed in Basilisk 52 out of the box; 1.17.7b2 of the dev channel was (has now been removed from the GitHub repo) equally the last (beta) version to install (out-of-the-box) in either Basilisk 52 / Serpent 52.9.0; this development has been reported first in the official PM forums, 

https://forum.palemoon.org/viewtopic.php?f=61&t=21241

which also links to the uB0 support reddit:

Mozilla fanbois aside (they're so irritating :angry:, aren't they?), it was claimed that "Basilisk was never officially supported", while in the end of the thread the author revealed that he had to increase "strict_min_version" (inside extension's manifest.json) to "55.0", because he started using the Web API requestIdleCallback. So, latest dev version 1.17.7rc2 won't install in Bk52 :realmad:

I've done some research and have discovered at least two discrepancies here:

1. For some inexplicable reason, Firefox versions 52.0.2 and 53.0.3 (release channel) as well as 52.9.0 (ESR channel) do not honour the "strict_min_version": "55.0" requirement and version uB0 1.17.7rc2 has no problem installing and working there...

2. While the MDN documentation states that window.requestIdleCallback() is "Implemented but disabled by default" in Firefox v53-55, I found boolean pref "dom.requestIdleCallback.enabled" extant (but defaulted to false) in all 3 mentioned Firefox versions (52.0.2, 52.9.0, 53.0.3); so, at least in theory, Firefox >=52.0 already meets the new requirement by @gorhill, provided the user manually flips "dom.requestIdleCallback.enabled" to true; what is even more important is the fact Moonchild devs have already defaulted that pref to true in Basilisk 52, so there's no actual reason why the Basilisk browser should be exempt from the list of supported (by latest uB0 WE) browsers - but, sadly, @gorhill does not follow closely Basilisk's development, hence his decision to block it based solely on its reported appVersion string :angry:; also worth noting is that Serpent 55.0.0/moebius doesn't exhibit this issue because, its appVersion string reporting 55.*, it already fulfils the new enhanced requirements...

To cut a long story short, I downloaded file uBlock0_1.17.7rc2.firefox.signed.xpi to disk and manually changed line 5 in manifest.json file to read:

     "strict_min_version": "52.0",

... then the extension had no problem installing and working as expected in Serpent 52.9.0 :cheerleader:

Of course, when Moonchild's new unfortunate plan (to remove WE support in Bk) bears fruits, this post of mine would be a moot one... :(

******************************************************************* 

Edited by VistaLover
  • Like 1
  • Upvote 2

Share this post


Link to post
Share on other sites

Wow - that didn't take long: 16 hours from @Sampei.Nihira's initial post to the actual code commit. (Of course I know it was actually longer since the PM team made the decision, but still....)

That means the commit will be in the next official Basilisk release. Guess we'll see how long @roytam1 can hold out.

Mozilla wants me to toss all my legacy add-ons; MC wants me to toss all my WE add-ons. AFAIK the only browser left that will support both is Waterfox. Not XP compatible; yet it might work on the Win 7 side - except it's a 64-bit browser, so I'd still need to replace all my 32-bit add-ons with 64-bit versions.

Three choices; three hassles. Why can't I just keep running the add-ons I have?

Share this post


Link to post
Share on other sites
9 hours ago, VistaLover said:

 

BTW, reddit, ghacks and the like are mostly infested by Mozilla fanbois, who never lose breath badmouthing all Firefox forks (including Pale Moon, Basilisk, Waterfox), so I never place credence to all the FUD they're spreading there... Yes, I am to an extent concerned with browser security, but usability is of primary importance to me...

Being on 32-bit Vista, this obviously holds little promise for me... Unless you're implying the Waterfox Team efforts would, somehow, find their way into your forked UXP copy (hence Serpent 52.9.0)... ;):whistle:

I will say that on ghacks, the only crap I spew on Pale Moon is directed at the team.  Marcus Straver and Matt Tobin are the epitome of (well you choose an expletive), so I will continue as I please to crap on those two, in addition to the fanboys that defend their actions at every turn.  For that I will NOT apologize.  All of the Lord Lestats and Alex's defend the team, even when no one in their right mind would do so.

 

Share this post


Link to post
Share on other sites

@Mathwiz What about roytam's build of Basilisk 55? It should still support WEs just fine.

  • Like 1

Share this post


Link to post
Share on other sites

Yes it does, and in fact it supports WE even better than 52, but I have a couple of add-ons (Abine's Blur and Exif Viewer) that are incompatible with 55. Also most of my plug-ins don't seem to work.

Share this post


Link to post
Share on other sites
17 hours ago, VistaLover said:

if one installs the XUL version of uB0, currently at version 1.16.4.7

THANKS to tip me to this (Jan 20, 2019) new Firefox LEGACY version of uBO EXTENSION. I thought GORHILL was finished doing any Firefox LEGACY extension updates. IF that GORHILL would soon do a Firefox LEGACY update to his uMATRIX extension, that would be VERY appreciated here too. I got the new uBO Firefox LEGACY extension working quickly in the RT Borealis Browser too. After modifying the INSTALL.RDF file as needed (no problem, see RT message, this thread on it).

Share this post


Link to post
Share on other sites

So for WebRTC protection, I too ended up going with uBO 1.16.4.7, for the following reasons:

  • Been using uBO anyway
  • Gorhill still maintaining the legacy version (1.16.4.7 was released 2 days ago)
  • No need for separate WebRTC add-on
  • No need to modify anything to allow installation (which would need to be redone for each update)
  • No need to disable WebRTC entirely in about:config

Edit: I should have known this, but didn't realize it until now. If you downgrade to 1.16.4.7 you need to turn off automatic updates, or Basilisk will just re-update you to 1.17.4.

Edited by Mathwiz
  • Like 1

Share this post


Link to post
Share on other sites

Wanna bet Mozilla will screw something up again and people will get back to Chrome yet again?

Edited by Tamris

Share this post


Link to post
Share on other sites

I don't think folks should have to click through to see what's being discussed, so TL;DR:

Quote

Google engineers have proposed changes to the open-source Chromium browser that will break content-blocking extensions, including ad blockers.

If the overhaul goes ahead, Adblock Plus and similar plugins that rely on basic filtering will, with some tweaks, still be able to function to some degree, unlike more ambitious extensions, such as uBlock Origin, which will be hit hard. The drafted changes will limit the capabilities available to extension developers, ostensibly for the sake of speed and safety. Chromium forms the central core of Google Chrome, and, soon, Microsoft Edge.

... Google's stated rationale for making the proposed changes, cutting off blocking plugins, is to improve security, privacy and performance, and supposedly to enhance user control.

...

But "better privacy" here means privacy as defined by Google rather than privacy defined by a third-party extension developer. That's fine in scenarios where Google is more trustworthy than a third-party developer; but if Google and its ecosystem of publishers and advertisers are the problem, then users may prefer allowing a third-party to filter network requests....

... Google and other internet advertising networks apparently pay Adblock Plus to whitelist their online adverts.

...

Following a huge outcry from plugin developers and netizens, Google has reiterated that the proposed changes are not set in stone, and are subject to revision. While the internet goliath wants to rein in the level of access granted to Chrome browser extensions, it is prepared to work through the messy matter with third-party coders – who will have to rewrite parts of their software if this all goes ahead.

So, it's still just a proposal, but I'd bet on more Chromium forks like Advanced Chrome if it goes through.

And Mozilla following suit would be MC's wet dream. The popularity of PM & especially Basilisk would increase tenfold overnight.

But since neither Chrome nor FF supports XP or Vista any more, none of this matters to us anyway.

Share this post


Link to post
Share on other sites

:worship: GORHILL FIGHTING !!! :worship:

(Raymond Hill ; uBO ; uMATRIX)

Edited by TechnoRelic
  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...