Details about UXP in 2018
Posted: 2018-02-01, 10:48
As people are aware, we've been developing on UXP for a while now which carries the Basilisk browser as its current "showcase application" and development vessel.
The problem
While platform progress has been steady, investigating the compatibility as a platform with Mozilla-style applications other than a matching Firefox browser application has turned up some very disturbing things, that can be summarized as follows:
Our fork point chosen when starting our Möbius platform development was optimal from a feature set and web technology point of view, but has turned out to be increasingly problematic when trying to use it for anything other than the single product Mozilla has focused on working towards in 2017: Firefox Quantum. Its immediate predecessors are already crippled in several ways and build on an inflexible in-progress code tree that is neither catering to other applications than the one supplied with it, nor will they or what they build on stand up to the test of time.
The severity and reach of these compatibility issues have only come to light very recently as we took steps to try and move Pale Moon code forward to Möbius, and finding some deep-rooted and very well hidden fundamental changes that were applied to the very core of the Mozilla code that could not be undone without completely unbalancing the tree.
The choice
This means a choice was forced upon us, after seeing that this damage (rapid rearchitecturing for Quantum, Rust, Servo and forcing e10s technologies in all components) could not be undone with simple patching or "working back" through the changes made. The choice being that we either had to choose a Mozilla path to continue as we were and focus on a single product with no regard to other applications (à la Waterfox), or to take a step back, re-fork, and focus on many applications being able to use the code tree to build upon.
Since we are steadfast in our resolve to provide a usable platform, the choice fell solidly on the latter of the two.
Doing this has pros and cons, of course. The pros being, as outlined, being able to build a solid foundation that has not yet been tainted with Firefox Quantum precepts and rearchitecturing, with high likelihood of other XUL applications working with minimal changes, GTK2 support for Linux being less broken, clearer choices of optional components being built or not for applications (WebRTC, EME, e10s). The cons being that we will have to re-do a lot of work to bring the new fork forward to our current UXP state-of-development and will need to add new implementations for what will be missing in the new fork that we carried over from our previously forked state (back-porting Mozilla developments like full WASM support and some missing ES6 features).
I think if we make a concerted effort, as a community, we can make this happen, and have the platform ready for beta before the end of summer 2018. We will need to show commitment, focus, and tenacity. We've seen our community can do this, when Tycho was in its early stages, so I'm confident we can make this happen if we work together, put in the effort, and above all keep in mind that we will be developing a platform for wide use, not for one or two applications or workflows.
What does this mean in practice?
In practice, it means we will be re-forking our base code to work from, from the Mozilla tree, at the ESR-52 level and go from that base forward. We're choosing ESR-52 to get as much official Mozilla support for security as possible allowing us to focus more directly on the amount of work needed to re-establish a solid UXP base, as well as that branch being the very last that can be used for our intended purposes (53 and later all have the architectural issues to varying degrees that make them unsuitable). Of course we will still be porting additional security patches that ESR releases normally don't get, to keep an as high security standard as possible regardless of developments.
Since we already know our targets in the tree, and can re-use our patches to a reasonable extent that have been used on Möbius, with research already done, we should be able to use very rapid development here. If all goes as planned, we may have both Pale Moon and our current Basilisk (both will be put in maintenance mode while we focus completely on UXP) on the new platform before the end of the year with a bright future ahead of us for both our products and others alike!
The problem
While platform progress has been steady, investigating the compatibility as a platform with Mozilla-style applications other than a matching Firefox browser application has turned up some very disturbing things, that can be summarized as follows:
Our fork point chosen when starting our Möbius platform development was optimal from a feature set and web technology point of view, but has turned out to be increasingly problematic when trying to use it for anything other than the single product Mozilla has focused on working towards in 2017: Firefox Quantum. Its immediate predecessors are already crippled in several ways and build on an inflexible in-progress code tree that is neither catering to other applications than the one supplied with it, nor will they or what they build on stand up to the test of time.
The severity and reach of these compatibility issues have only come to light very recently as we took steps to try and move Pale Moon code forward to Möbius, and finding some deep-rooted and very well hidden fundamental changes that were applied to the very core of the Mozilla code that could not be undone without completely unbalancing the tree.
The choice
This means a choice was forced upon us, after seeing that this damage (rapid rearchitecturing for Quantum, Rust, Servo and forcing e10s technologies in all components) could not be undone with simple patching or "working back" through the changes made. The choice being that we either had to choose a Mozilla path to continue as we were and focus on a single product with no regard to other applications (à la Waterfox), or to take a step back, re-fork, and focus on many applications being able to use the code tree to build upon.
Since we are steadfast in our resolve to provide a usable platform, the choice fell solidly on the latter of the two.
Doing this has pros and cons, of course. The pros being, as outlined, being able to build a solid foundation that has not yet been tainted with Firefox Quantum precepts and rearchitecturing, with high likelihood of other XUL applications working with minimal changes, GTK2 support for Linux being less broken, clearer choices of optional components being built or not for applications (WebRTC, EME, e10s). The cons being that we will have to re-do a lot of work to bring the new fork forward to our current UXP state-of-development and will need to add new implementations for what will be missing in the new fork that we carried over from our previously forked state (back-porting Mozilla developments like full WASM support and some missing ES6 features).
I think if we make a concerted effort, as a community, we can make this happen, and have the platform ready for beta before the end of summer 2018. We will need to show commitment, focus, and tenacity. We've seen our community can do this, when Tycho was in its early stages, so I'm confident we can make this happen if we work together, put in the effort, and above all keep in mind that we will be developing a platform for wide use, not for one or two applications or workflows.
What does this mean in practice?
In practice, it means we will be re-forking our base code to work from, from the Mozilla tree, at the ESR-52 level and go from that base forward. We're choosing ESR-52 to get as much official Mozilla support for security as possible allowing us to focus more directly on the amount of work needed to re-establish a solid UXP base, as well as that branch being the very last that can be used for our intended purposes (53 and later all have the architectural issues to varying degrees that make them unsuitable). Of course we will still be porting additional security patches that ESR releases normally don't get, to keep an as high security standard as possible regardless of developments.
Since we already know our targets in the tree, and can re-use our patches to a reasonable extent that have been used on Möbius, with research already done, we should be able to use very rapid development here. If all goes as planned, we may have both Pale Moon and our current Basilisk (both will be put in maintenance mode while we focus completely on UXP) on the new platform before the end of the year with a bright future ahead of us for both our products and others alike!
