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

On 1/15/2019 at 8:08 PM, caliber said:

watch later button (lower right corner) is missing on youtube under PM28

... This is because Pale Moon 28 (New Moon 28) has a native Site-Specific-User-Agent-Override (SSUAO) for youtube.com that forces it to display in the older ("Classic") web style, which lacks, among other things, the "Watch later" button (placed after "Share" button in the new "Material" web style). 

general.useragent.override.youtube.com;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 PaleMoon/28.3.0a1

If you want to force the new "Material" design for youtube (and thus make the "Watch later" button available to you in NM28), you should modify the SSUAO to spoof a recent Mozilla Firefox version:

general.useragent.override.youtube.com;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0

Be warned that the Material youtube design works better in more recent hardware (namely GPU/CPU)... ;)

  • Like 1
  • Upvote 1

Share this post


Link to post
Share on other sites

Good riddance! :yes:

Share this post


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

"but Basilisk reports that they all appear to be corrupt. Must be a bad hash somewhere" :

This is a generic message given out by Basilisk/Serpent when the WebExtension addon one attempts to install is somehow unsupported/incompatible; only rarely does it actually indicate a corrupt file (due to, e.g., erratic connection during download, etc.).

In the case of the referenced extension, the error is caused by a limitation in the set of WebExtension APIs present in Basilisk/Serpent (which, as you know, is only a subset :angry: of the WE APIs present in the MozillaESR 52 platform, that UXP forked) ... In fact, Basilisk/Serpent have no support for id-less WE addons, hence the generic error message produced...

Easy workaround: Once you download to disk file webrtc_control-0.2.3-an+fx.xpi, open it with 7-zip archiver; first, you can optionally delete the whole META-INF directory, to reduce addon size, since Basilisk doesn't check for extension signing; then, open file manifest.json in an editor and, towards the end, add an arbitrary extension-id, e.g. I added:

(modified file, shown here is excerpt starting at line 31)


    "128": "data/icons/128.png"
  },
  "applications": {
    "gecko": {
    "id": "webrtc-control@basilisk.org"
    }
  }
}

Save your patched .xpi file (for me, once I exit my text editor, 7-zip auto-prompts to save the committed changes) and then install to Basilisk via drag-n-drop; it should install now without errors.

Thanks for the clarification. Good to know that "appears to be corrupt" might only mean "not supported."

Since I, personally, don't use WebRTC, I just disabled it in about:config on my browser. But as I posted, someone who does use WebRTC needs a more convenient way to toggle it on/off.

  • Like 1

Share this post


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

As discussed previously, the WE version of an add-on is preferred over its legacy version when the browser is to be (force-)run in multiprocess (e10s) mode ;) ...

 

5 hours ago, Sampei.Nihira said:

I get their point; but the obvious problem is, some of us are already using some WebExtension add-ons in Basilisk, so this breaks compatibility with our browser set-ups. IMO it would be better to leave WebExtensions in the code & just not do any further development on them (except for security fixes).

Editorial: I wonder if the PM team is unclear on the problem with WebExtensions. As I see it, the problem isn't that they exist; the problem is that Mozilla decided to force everyone to rewrite their add-ons to use them, in order to install on newer FF versions; thus disabling any legacy add-ons that weren't actively being maintained. This is the main reason I switched to Basilisk in the first place - I didn't want to have to find replacements for all my legacy add-ons - but now the PM team is about to make the exact same mistake, in the opposite direction!

Maybe there are also a couple of unstated reasons for the PM team to remove WebExtensions from Basilisk:

  1. To remove any incentive to move from PM to Basilisk in order to use newer WebExtension add-ons
  2. To further incentivize add-on developers to maintain legacy versions of their add-ons
1 hour ago, roytam1 said:

don't know if I will follow or not

I may have to start using your XP builds even on Win 7, just to keep compatibility with my existing set of add-ons.

Edited by Mathwiz
  • Like 3

Share this post


Link to post
Share on other sites
1 minute ago, Sampei.Nihira said:

XUL and Wes could not coexist for a long time.

 

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

  • Like 3

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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
Guest
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...