Mozilla Code Repository fork Unified XUL Platform
M.C.Straver, the lead developer of the Pale Moon web browser, has created a fork of the Mozilla Code Repository as a starting point for further development.
The developers of Pale Moon, a browser based on Firefox code, had to find a way to deal with the changes that Mozilla planned to make to the core of the Firefox web browser in 2017.
Mozilla plans to cut the classic add-on system from Firefox when Firefox 57 hits for instance, and remove XUL and XPCOM components from the browser in the process.
The team decided that it would continue development of the classic Pale Moon browser; what this means for users is that Pale Moon will continue to work like before, but won't follow Mozilla down the path.
The decision was made to fork Mozilla's code repository, so that it could become a potential base for Pale Moon in the future. It is not a given at this point that Pale Moon will use UXP in the future.
The GitHub repository of the Unified XUL Platform (UXP) is now available. According to its description, it is a fork of the Mozilla-Central code repository of early 2017.
The repository will have patches integrated from Mozilla Code, use Mozilla upstream code for development, and independent updates from Mozilla Code added to it.
This repository holds the code for a unified application platform for XUL-based applications. It is a hard fork from the Mozilla code repository (mozilla-central) with an early-2017 fork point.
In addition to further development based on the Mozilla upstream code, and selective cherry-picking of directly-applicable patches, this repository has its own development and holds the base for a future platform to be used by XUL applications.
Probably most interesting from a user's point of view is that a demonstration application will be released that is codenamed Basilisk. It is a web browser and will resemble the early 2017 Firefox closely.
This repository will contain at least one application to demonstrate and make use of the platform: The Basilisk web browser, a close twin to Mozilla's Firefox.
The web browser has not been released yet.
The minimum system requirements for any application based on the Universal XUL Platform have been announced in May 2017:
- At least 1GB of system memory (some may run in less).
- A processor with SSE2 support.
- Windows: Windows 7 or newer.
- Linux: Recent kernel and system libraries. Focus on GTK3.
- Mac OS X: At least Mac OS X 10.9.
Verdict
The Unified XUL Platform takes shape, and it will be interesting to see how it develops over time. Many things are uncertain at this point. How many developers will it attract? Will Pale Moon use it as its base in the future? Will other applications be created based on it?
Now You: What's your take on this development?
AMO and XUL must be preserved, at least as “legacy” code to review, experiment and as “History”, not purging “old” replacing with now” that is dangerous
ArchiveTeam is listening about AMO
from
archiveteam DOT org/index.php?title=Alive…_OR_ARE_THEY
“addons.mozilla.org – On November 2017, Mozilla will release Firefox 57, which will only support WebExtensions.[1] It is curently unclear what exactly will happen with the thousands of “legacy add-ons”. Currently, later versions of Firefox will be unable to download these addons, though the download link can still be easily reached by digging into the source code.”
Its a big undertaking for such a relatively small team like pale moon.Its time consuming just to keep pale moon updated nevermind taking something else on too.
How on earth can half a dozen people at most maintain such a code when a global community struggles.?
Time will tell.
That’s my thinking as well. How many people does the Pale Moon team consist of?
If this is a project to preserve the foundations of the classic Mozilla GUI and UX, for the time when Firefox
eventually abandons them in the near future, why is there a screenshot of Google Chrome showing the
relevant page on GitHub, but not Pale Moon, SeaMonkey, or even Firefox itself??
Because that’s probably the browser Martin used to create a screenshot for the article here, while visiting the project’s GitHub page. I fail to see how that is relevant… with anything. The screenshot belongs to the article here, not to the project.
What’s “Unified” about this?
What makes this any more of an applications “Platform” than the ‘well, it can do all sorts of things apps can do, but good luck shoehorning it into even a basic Hello World app … you’re on your own there’, which was the Mozilla approach even before the abandoned it as a cross-browser, open-source, web-oriented platform. Don’t get me wrong, I’d love to see it succeed in such a context. Anything has got to be better than bloody Electron’s enormous ‘runtime’. However it would be (delightfully) surprising to see this UXP repo attract enough browsers to maintain a browser based on it. If Mozilla … all dubious leadership / priorities notwithstanding … couldn’t even support the “Platform” in the Seamonkey, Thunderbird or any other context, there’d need to be some serious developer interest to build a genuinely usable, portable, secure and compact “Platform” foundation for developers.
That is, unless the “WebIDE” is something more genuinely akin to a desktop “Platform” development IDE than it’s name implies.
Mozilla pretty much seems to have admitted failure to make any existing, XUL-supporting codebase into an embeddable, developer-friendly engine, platform or runtime:
`Servo intends to re-implement the Chromium Embedded Framework (CEF) API. This would allow Servo to be used as a drop-in replacement for Chromium in applications using CEF, and positions Servo as a competitor to Chromium in these cases`
It is v52 code with changes.
I’m expecting 56 to be good release (a few performance improvements.) So far doesn’t look like anyone else stepping up to support a pre 57 fork. Most likely another fork might happen after 57 is released, if someone deems it to be too much of a dud.
GTK3 actually, not GTK2.
Thank you!
Looking at the size of the project it’s no wonder Mozilla wants to rip it out. Just look at the size of the XUL dll if you have Firefox on Windows. It’s over half of the entire Firefox installation.
The xul dll contains a lot more than xul parsing code. It contains most of the entire platform (all html/dom/media parsing, layout, rendering, etc), and is not a reflection of the size of the XUL format parser (which is a LOT smaller and just a fraction of that dll size).
Once upon a time, Mozilla decided that a monolithic dll for “the browser engine” was a good idea, and more and more has been folded into it over time. Although named xul.dll or “libxul”, it is not just XUL code.
So it’s just poorly named. I apologize, I did not know that.
@NiLSPACE: You got this totally wrong. XUL will still be an important part of Firefox 57+ – Firefox will just not support the XUL/XPCOM add-ons anymore. This does not mean that XUL itself will go away. Replacing XUL in its entirety is a complex process and will still take months, if not years. By the way – as Tom Hawack has already said – the size of a library is not necessarily related to its performance. Should Mozilla make use of HTML instead of XUL in the future you should prepare yourself for a package as big, if not bigger in size.
Yeah, I know, but by deprecating the add-ons they can at least start working on the internals.
Also, as I said earlier, I never said it ran slow, but it’s huge and hard to maintain alone.
Firefox always ran fast and smooth here whatever the size of the XUL library. Webextensions will make it easier for the devs to include gadgets and various optimizations which will bring pages’ rendering a fraction of a fraction of a second faster at the cost of users’ ability to enjoy the power of legacy add-ons. It’s the company’s choice. Arguable and argued.
When people keep repeating like a broken record that they don’t use Firefox for Android because “it’s not as fast”, you know Quantum is necessary.
Though Firefox for Android kicks ass on my lame phone.
I never said it ran slow. Just that it’s huge, and is hard to maintain alone.
Well, it is the main reason why I use FireFox. As to Mozilla’s reason, idk. They don’t seem to know what they are doing. Look at v54 and the nonsense they have done to the downloads flyout.
Considering Firefox got a very noticeable speed boost not once but twice in the last 12 months for me, once for E10S and once for Firefox 53, which also brought a dark small theme that fits my customisation very well, I’m very happy to see the browser wake up as years of preparatory work are reaching release channel every couple months.
YMMV. To me the download panel thing is but a pebble on a brand new marble road.
I’m not sure why they did that to the downloads either, but the reason to step away from XUL is as I said that it’s huge. And since they are the only ones to work on it it’s tough to maintain it.
What is going to happen to all the addons listed on addons.mozilla.org once Firefox 57 is released, will they all get removed immediately, or will they continue hosting them for projects like this? Or will they have to be self hosted?
I suggest to backup the ones you want to keep. Do a new backup every now and then after updates.
Just in case they over night turn the key and the site is gone.
If you install them you can then find them in
C:\Users\”user”\AppData\Roaming\Mozilla\Firefox\Profiles\”your profile”\extensions.
Or follow the appropriate path for example if you use cyberfox that has its own folder instead of mozillas standard path.
And keep a bookmark of the devs who has setup their own website and hosting the extension.
For example https://www.ublock.org/ or page info button http://www.wirble.de/pageinfo/
Or perhaps we could submit add-on webpage to Wayback Machine?
Tested now but backing up the direct link didn’t work because of robot.txt.
https://addons.mozilla.org/firefox/downloads/latest/page-info-button/addon-1596-latest.xpi
Be creative
Thanks Tom Hawack. Why didnt I think of that. I was right there copying the direct link anyway. Took me just a minute to download all 31 of them I want to keep.
I compared the hash (MD5, SHA1, CR32, SHA-256,512,384) of all my extensions from my profile\extensions folder and all I downloaded from AMO and they are the same.
If you compare the hash with a match I would say its safe to use the file. Hash your files to start with and keep this copy in a text file to compare with in the future if you suspect the files has been modified if you have some issues.
Complete themes can be downloaded the same way. They are contained in the same .xpi file type.
Personas themes I found can be downloaded by simply saving the whole webpage. CTRL + S.
Because there is no file to be downloaded. I opened the .htm I saved on a different computer without internet and it shows the normal webpage and asks if i want to apply the theme when I click “Add to firefox” and so it does successfully.
One might as well go to AMO, right-click on the add-on’s ‘Add to Firefox’ button-link and choose ‘Save link as…’. To be noted : I’ve encountered sometimes a problem when trying to download the add-on’s xpi file as mentioned above, in which case proceeding from that add-on’s install button but from its ‘See complete version history” page (the /versions page) is never problematic.
I wouldn’t advise considering the installed add-on location in the user’s profile\extensions folder as a suitable base for backuping when the aim is to later on reinstall from that backup : you need a clean .xpi file to install an add-on, pasting back can lead to problems, really not the right way to proceed.
Good question. I’d believe those legacy add-ons will remain on AMO at least until the end of the 52 ESR lifetime (Q1-2017)
@Jody, >”After all, the pages are loaded with add-ons that are no longer compatible with the current Firefox.”
Pertinent and apparently a logical confirmation that the ESR branch is concerned.
That’s what I’ve also heard up until now. Makes sense they’d remain for ESR users. After all, the pages are loaded with add-ons that are no longer compatible with the current Firefox.
I’m guessing the “Support” in “ESR” refers to FF only, not the add-ons, since they’re made by individuals, not Mozilla. So, they might get removed as soon as FF57 is released.
How can we make a local backup of the entire AMO repository is the question.
I second this. They will remain there at least until the release of Firefox 61 (EOL Firefox 52 ESR). The subsequent Firefox 59 ESR will not support them.