Jump to content

My Browser Builds (Part 2)


Recommended Posts


Just thought the following would interest people using the UXP forks:

It is the personal goal of upstream developer M.A.T. (but also backed-up by Moonchild himself) to completely debilitate all Firefox-targeting "legacy" extensions from being installable in official UXP browsers like Pale Moon/Basilisk...

Already, unstable Pale Moon 29.0.0a6 official builds come without the buildconfig option "--enable-phoenix-extensions", which means already installed compatible Firefox XUL extensions will be disabled :(, with no option to re-enable :realmad: , while "new" ones (e.g. from CAA) can no longer be installed :angry: ...

One way to circumvent that artificial block is to manually edit the add-on's install.rdf file to include a Pale Moon specific <em:targetApplication> section... Or, for a more automated/user-friendly procedure, install and use JustOff's MTT:

https://github.com/JustOff/moon-tester-tool/

A confrontation between M.A.T and JustOff has been brewing for some months now (on several levels), let's just say that M.A.T wasn't enthused by the CAA extension nor the recent update of the MTT one ;) ... In a recent post:

Quote

And they won't work eventually even if you manually add a Pale Moon targetApplication block to indtall.rdf.
100% probibility. <snipped>
All Unified XUL Platform application extension and theme developers please pay attention and be ready. The future applies to you as well.

What future M.A.T. refers to is tracked in official UXP issue #1659 and work on it has already started: 

https://repo.palemoon.org/MoonchildProductions/UXP/commits/branch/xpiprovider-work

I'm not implying, though, that official devs have any ill intent; their view on things is that they should (forcibly) migrate their users from long-deprecated, "insecure", no-longer-maintained Firefox specific legacy extensions (e.g the ones provided by CAA) - despite the fact they are currently working OK - to PM-exclusive format and extensions, forks of the original ones, with current maintainers sourced from the UXP communities (and elsewhere) ... :whistle:Lofty as it may sound, the net result is yet another wave of plain user inconvenience...

Should we be concerned? I'm not yet sure... :dubbio: I don't know what fate awaits the --enable-phoenix-extensions buildconfig flag; if the supporting code stays put, then we should be OK with regards to Fx XUL add-ons; however, in due course, upstream extensions and their repositories will move to the new format, which we'll have to somehow support too, if we are to make use of (or abuse of, as upstream claim :( ) ... Is supporting both formats (old: install.rdf, new: install.json) in the core browser a possibility, even? I'm no coder, so can't say myself... But, definitely, this part of the official UXP development is one our maintainer @roytam1 should keep a close eye on... :whistle:

Best wishes, stay safe :)

Edited by VistaLover
Link to comment
Share on other sites

14 minutes ago, VistaLover said:

Just thought the following would interest people using the UXP forks:

It is the personal goal of upstream developer M.A.T. (but also backed-up by Moonchild himself) to completely debilitate all Firefox-targeting "legacy" extensions from being installable in official UXP browsers like Pale Moon/Basilisk...

Already, unstable Pale Moon 29.0.0a6 official builds come without the buildconfig option "--enable-phoenix-extensions", which means already installed compatible Firefox XUL extensions will be disabled :(, with no option to re-enable :realmad: , while "new" ones (e.g. from CAA) can no longer be installed :angry: ...

One way to circumvent that artificial block is to manually edit the add-on's install.rdf file to include a Pale Moon specific <em:targetApplication> section... Or, for a more automated/user-friendly procedure, install and use JustOff's MTT:

https://github.com/JustOff/moon-tester-tool/

A confrontation between M.A.T and JustOff has been brewing for some months now (on several levels), let's just say that M.A.T wasn't enthused by the CAA extension nor the recent update of the MTT one ;) ... In a recent post:

What future M.A.T. refers to is tracked in official UXP issue #1659 and work on it has already started: 

https://repo.palemoon.org/MoonchildProductions/UXP/commits/branch/xpiprovider-work

I'm not implying, though, that official devs have any ill-intent; their view on things is that they should (forcibly) migrate their users from long-deprecated, "insecure", no-longer-maintained Firefox specific legacy extensions (e.g the ones provided by CAA) - despite the fact they are currently working OK - to PM-exclusive format and extensions, forks of the original ones, with current maintainers sourced from the UXP communities (and elsewhere) ... :whistle:Lofty as it may sound, the net result is yet another wave of plain user inconvenience...

Should we be concerned? I'm not yet sure... :dubbio: I don't know what fate awaits the --enable-phoenix-extensions buildconfig flag; if the supporting code stays put, then we should be OK with regards to Fx XUL add-ons; however, in due course, upstream extensions and their repositories will move to the new format, which we'll have to somehow support too, if we are to make use of (or abuse of, as upstream claim :( ) ... Is supporting both formats (old: install.rdf, new: install.json) in the core browser a possibility, even? I'm no coder, so can't say myself... But, definitely, this part of the official UXP development is one our maintainer @roytam1 should keep a close eye on... :whistle:

Best wishes, stay safe :)

I was able to use MTT to bypass that, and all my old extensions worked fine, but I don't understand why create their own extension format? It sounds less like they want to further XUL development, but instead further their own extension types while making the less knowledgeable users switch to a different browser.

I don't think most extension developers would want to break their legacy extensions on other browsers, so I don't think this and the install.rdf changes will go too well.

Link to comment
Share on other sites

Does anyone know if the Classic Add-ons Archive is down or not working properly? When I try to actually connect to it to download the extension, nothing seems to happen.

 

I can do a search and get results, but no download.

 

 

Edited by Omntech
Link to comment
Share on other sites

On 11/5/2020 at 6:59 AM, soggi said:

Nice to hear about that, thanks! I'll test it with the next build. :)

Thanks @roytam1 for finally fixing the JS bug concerning heise.de and YT!

BTW the mirror has been updated with the latest versions of BNavigator, MailNews, New Moon 27, New Moon 28 and Serpent 52 -> soggi.org - tools.

kind regards
soggi

Edited by soggi
Link to comment
Share on other sites

4 hours ago, Omntech said:

Does anyone know if the Classic Add-ons Archive is down or not working properly? When I try to actually connect to it to download the extension, nothing seems to happen.

 

I can do a search and get results, but no download.

 

 

Which extension?

You can download CAA from its github releases page.

I just checked inside CAA and was able to download a random extension.

Link to comment
Share on other sites

@soggi : A small inconsistency I'm seeing at your "mirror" :) :

lyaAgFr.jpg

The link to Serpent 55/moebius 64-bit package should be modified accordingly (to be uniform with the rest of the links to 64-bit browser packages ;) ...) ; other than this, many thanks for carrying the torch... :thumbup

Link to comment
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...