Pale Moon Highlight Problems With Following Firefox
Written by Mike James   
Wednesday, 23 March 2016

Pale Moon is a browser that tries to put right all that is wrong with Firefox. But, being a fork of Firefox, it brings with it some interesting problems. Now the Pale Moon team are contemplating starting over because of the churn in the Firefox code base. 

palemoonbanner

 

Pale Moon doesn't have a huge market share. However, its users tend to be passionate about using it. It is a fork of Firefox Extended Support Release 24 which seems like a reasonable choice on which to base another browser. After all, Extended Support suggests that bugs will be fixed.

Pale Moon keeps the original fully customizable Firefox UI and adds a range of efficiency and security extras.  Its supporters claim that it has gone down the road that Firefox should have gone down rather than copying Chrome and ignoring core features.

Being a fork of Firefox doesn't insulate you from Mozilla's decisions. In a post on the Pale Moon forum MoonChild, the project's lead developer, has raised the subject of how to progress MoonChild in the future and suggests the best option would be to start over. 

The problem is that while the Pale Moon community has been adding features the web has moved on. The version of Firefox that it forked may be Extended Support, but this doesn't mean that Mozilla goes back and adds features such as ES6, promises and new CSS support. In addition Mozilla is changing the Firefox architecture in radical ways. The simple fact is that Pale Moon doesn't have the manpower to implement the upgrades to the code that they inherited.

You might think that the code in the latest Firefox could be used to implement the upgrade but as MoonChild reports:

"... the Mozilla code has been very unstable, not just from a product view (although it's been one of the main reasons we forked when we did) but from an actual code structure point of view. This is mainly because of some rapid changes that started happening with many refactoring changes upon refactoring changes, e10s and FirefoxOS considerations that fundamentally changed some of the underlying structures, not to mention changes in coding style, which makes porting code increasingly difficult (and regularly impossible) because they build on (and were designed for) the changed underlying structures."

He goes on to say:

"Mozilla code has become extremely heavily reliant on templates, classes, overloading, virtualization of functions and many, many stub and redirect functions to "pass the buck" to the correct module to process things in, which makes working with the code base very difficult."

There is also the small matter that Mozilla has moved to using Visual Studio 2013, which has introduced breaking changes to the original code base which used VS2012.  Put simply, Pale Moon can't compile the new code with its compiler and can't compile itsold code with the new compiler. 

The suggestion is that the best way to get out of this trap is to re-fork the Firefox code at a more up-to-date point, but not so up-to-date that the architectural vandalism that is being inflicted has much effect:

"This re-forking would be done on the last stable version of Mozilla code that hasn't had a sledgehammer put to it yet and that offers the features and capabilities we as a project would still want (i.e.: Sync 1.1, XPCOM binary components in extensions, XUL, XBL, complete theme support, etc.)."

This would still mean that Pale Moon could support a lot of the old Firefox features that makes it so attractive but it would mean that it would have to re-implement all of  its code extensions and modifications all over again - not a nice prospect. However, when you think of it in terms of the stark choice between working on someone else's unknown undocumented code or reworking the code you created and know, it doesn't seem like a bad idea. 

Whatever the Pale Moon community decide,s it is a lesson to all of us that forking a code base because you are dissatisfied with the direction of the original product isn't quite the solution it seems to be. As soon as you start to mutate the fork you introduce incompatibilities with the original and can no longer take advantage of the progress that the progress it is making. In the case of Firefox the problem is made worse by the radical changes in architecture that are being implemented and the high rate of code churn. This may all seem obvious, but when you fork a code base that is much bigger than your community can work with then you are doomed be left behind. 

The problem is that if Pale Moon reforks then the chances are the same thing will happen in a few years. 

 

palemoonicon

More Information

Idea for a new browser product

Pale Moon

Related Articles

Mozilla Jumps On IoT Bandwagon 

Mozilla Confirms End of Firefox OS For Smartphones 

Brendan Eich Launches Brave New Browser 

Firefox To Adopt Chrome Extensions 

 

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on, Twitter, FacebookGoogle+ or Linkedin

 

Banner


Flutter Forked As Flock
05/11/2024

One of developers who worked on the Flutter team at Google has created an open-source form of the framework. Matt Carroll says Flock will be "Flutter+", will remain constantly up to date with Flutter, [ ... ]



Azure Container Apps Dynamic Sessions Generally Available
02/12/2024

Dynamic Session support has been added to Azure Container Apps. Azure Container Apps is a serverless platform for running containerized applications, and dynamic sessions is designed to provide fast a [ ... ]


More News

 

espbook

 

Comments




or email your comment to: comments@i-programmer.info

 

 

 

 

Last Updated ( Wednesday, 23 March 2016 )