The longer-term future of Pale Moon
The most important thing to mention for the longer-term future of Pale Moon is that we are dedicating ourselves to a major code changeover to a new code base and rewriting important parts of the browser and the toolkit it bases upon. This has been touched on in past discussions when talking about a new browser product. We do not currently have a public-ready prototype yet for this browser based on new code (a few things are still quite broken) but we are making steady progress and the end result will give us the solid, desired base to build our browser upon for the foreseeable future. With this changeover, there will be a stronger focus on current technologies with good opportunities to extend and keep pace with significant developments on the web. This new milestone will, therefore, have a number of additions that have initially not been on our implementation agenda, so our current roadmap won't paint a full picture of the browser as it will eventually be -- this roadmap will be updated once we are closer to completing our goals and have a better handle on what we are and are not including in the new milestone.
Our application code (our front-end/UI) will remain mostly the same, which will give our current users a familiar, customizable interface on their window to the web. Under the hood, however, there will be big changes. To understand what this means, the basic structure of our browser needs some explanation: Our browser code is divided into several different components: networking, rendering, scripting engine, layout engine, toolkit and front-end. What end-users see and work with is the front-end (and to some extent the toolkit) -- these are the components that make an application what it is, e.g. Firefox, SeaMonkey, Pale Moon, Thunderbird, FossaMail, Sunbird, etc.
The other components are part of the back-end, which is what drives these applications and provides the platform to build the application on. Setting aside our own platform changes (Goanna), Pale Moon will build on this common (Mozilla-derived) platform, but the application code (front-end) and to some extent our toolkit, meaning the code that makes the application what it is and what is exposed to the users of the browser, will be and remain our own. So there is literally no Firefox application code, and it will not be "based on a specific version of Firefox".
Highlighting a few of the improvements that are planned:
- Full support for DirectX 11 on Windows to take advantage of graphics acceleration. This will bring the browser in line with current graphics drivers and hardware in a more native way.
Our current support level is DX 10 on supported operating systems.
- Full support for HTTP/2.
- Native support for Ruby Annotations in the parser (our current method is a much slower post-layout reformatting based on work by the talented Keiichi Shimamura).
- Support for MSE/DASH video streaming and more advanced handling of media files.
Perhaps a more burning question for our current users is what we will continue supporting. We will continue to use/support:
- The Goanna engine. With the milestone it will be the third iteration of this engine going forward.
- Our time-tested user interface with full customizability.
- XUL/XBL as our main UI and interface language.
- Overlay/XUL (native UI) extensions with a little work. See below for important notes about extensions.
- Extensions with binary (XPCOM) components.
- Full themes and lightweight themes.
- Sync 1.1 (Our current and secure Pale Moon Sync).
- Advanced font styling (full graphite shaping support).
- NPAPI plugins.
- The Camellia encryption cipher.
Because of the changes as well as a re-balancing needed to keep the amount of work and code manageable for our team, there are however some negatives to this change as well. If we are going to move forward in a sustainable way, some parts of our support will have to be dropped.
We will have to:
- Drop support for Windows XP entirely. Targeting the NT5 era of operating systems as a valid platform would require extensive extra measures and code paths to maintain for a generation of operating systems that is by now well past its end of life. Keeping things XP compatible would hold back our development potential.
- Drop our current localization. Although our current language packs are a good method to localize the browser, the extensive changes would also mean that all language packs would have to be completely reworked, as well as the problem that we cannot move our user interface development at the pace we would like to if for every string change we would be reliant on our translators to follow suit on the short term. We also do not currently have an automated localization framework to help us out with such a big task, and are short on the manpower to organize this properly, to boot.
Pale Moon's new milestone will initially be English-only as a result. We may return to offering localizations for some major languages around the globe later on when our code base has sufficiently settled, but it will require a completely new setup (and time).
- Potentially drop support for Jetpack/SDK extensions. Our hybrid browser will almost certainly no longer sufficiently fit the bill for this kind of extension, especially considering most SDK extensions are specifically focused on and written for Australis, which we will never have. Although this may slightly raise the threshold for new add-on developers, creating native overlay extensions isn't exactly rocket science either.
Important notes about extensions
As indicated above, extensions will need some reworking to be compatible with our future Pale Moon. Pale Moon isn't Firefox, and with the new milestone, the differences will place it solidly apart to where extension developers will simply be expected to target us specifically or it will likely cause major issues. More so than before, I'd like to stress that our current ability to install Firefox extensions in Pale Moon is meant to be transitional behavior.
Mind you, the actual code changes needed may likely not be extensive, but at the very least it should be a conscious developer decision to release their extension for our target application instead of the topsy-turvy world where we are expected to make Pale Moon conform to/compatible with an extension that wasn't even written for us in the first place.
Because Mozilla is deprecating extensions as a whole (including Jetpack/SDK) in favor of "WebExtensions", there won't be any common ground left apart from legacy Firefox extensions that Mozilla won't support anymore, and SDK extensions kind of fall through the cracks as never having been very compatible with us to begin with and now being deprecated to boot. So, ultimately, there may also be no reason to extend our current transitional support for installing Firefox extensions that are factually targeting a different browser, but we'll have to see to what extent compatibility can be retained. With Mozilla planning a complete changeover, we will effectively be fully inheriting the XUL/XBL way of writing extensions the way they have been created for most of Firefox's lifetime.
The near future of Pale Moon
As you can imagine, something like this will take a considerable amount of time. So, for the near future, nothing will change for Pale Moon and we will continue to develop and publish updates to our current v26 era browser while the new milestone is developed further.
As the new milestone will develop further, we will publish public betas to involve our community in giving it shape, and to give extension developers plenty of time to try out their extensions on Pale Moon and make necessary changes before it is released as final.
I'll be more than happy to answer any specific questions about this change.