Pale Moon Downloads
Release Notes

This is a major step forward for compatibility.  If you have had troubles with any sites, now is the time to try them again.  Somewhere between 80 and 90% of the problematic web sites were fixed or at least made usable in the last 3 months.

Pale Moon 32.1.1 has been released! This is a bug fix, security update.

Please head to the download page to get the latest releases.

The Intel version is codesigned but not notarized because Apple now requires 10.9 target for notarization (we target 10.7).  Please visit the Pale Moon Forum and vote if you want the version bumped to 10.9 so it can be notarized.

The Apple Silicon (ARM64) version is both codesigned and notarized.

I am requesting input about notarizing Pale Moon builds on the Pale Moon forum.

https://forum.palemoon.org/viewtopic.php?f=41&t=29707

If you can go there and give me your response... if you don't have an account there you can post your response here too.

Thanks!
Brian

I have started doing official builds of Basilisk for MacOS, FreeBSD and ARM64 Linux...

Download them from the Basilisk site!

Release notes.

Fixed some minor issues in the processes of engineering this release.  Fixed drawing in the titlebar with later versions of MacOS, so it doesn't need the theme modifications that Silver had been using. Fixed WebRTC support on FreeBSD and fixed JPEG-XL support on ARM64 Linux.

Enjoy!!

Pale Moon 32.1.0 has been released! It is a huge step forward in Web compatibility.

Please head to the download page to get the latest releases.

I am no longer releasing dual branded versions with White Star.  White Star branded versions will now be my experimental Mac builds where I try out new Mac (or FreeBSD) specific features and updates.

I spent the money that people have donated for Mac development to get the Mac builds notarized with a developer account. This should alleviate some of the issues people had with the builds getting quarantined after downloading. Thanks to all who donated and if you want them to remain notarized please continue to donate, since this will be a yearly expense.

I have posted beta versions for Mac and FreeBSD.... if anyone is interested in pre-testing... but it is beta so backup your profile before hand.

This versions enables WebComponents which allows a lot of sites that didn't work before to work now. However this code has largely been untested due to a blocker bug.   We want as much testing as possible to flush out possible problems before the next release.

Get it from the links on the Pale Moon forum... also post any crashes or problems there! Thanks!

https://forum.palemoon.org/viewtopic.php...28#p237198

Also, if you were using the PaleFill extension, you should disable it... as it should no longer be necessary for most things.

I recommend everyone go to the Pale Moon site and get the Pale Moon branded version from there!

If you have issues with the Pale Moon version you can get the White Star branded versions here:
Download Intel Build SHA256: e5b6f1f8dd0dff1adbb5b4f2b97dfd563d0ac12004df8061092123b035bad3d7
Download Apple Silicon (ARM64) Build SHA256: 47143ff37b6a9f662d58e28a2331d2e1972776cc22722f64f6922619c818f638
Download FreeBSD 12 (AMD64/GTK3) Build SHA256: e63f747d243dcf115037374a65e69a85d91ef33dcc8169e68116a3f461fddac1
Source Code Git: White-Star UXP
Release Notes

This is a bug fix and security update.

I recommend everyone go to the Pale Moon site and get the Pale Moon branded version from there!

If you have issues with the Pale Moon version you can get the White Star branded versions here:
Download Intel Build SHA256: e42decb79c7371e01f271a334a248ec14669f8e07d04e9bdcc7a918879e44c2d
Download Apple Silicon (ARM64) Build SHA256: 8de67d363810f671966bf57a80d75f8b0598cb4c200fff99347d742aa7637538
Download FreeBSD 12 (AMD64/GTK3) Build SHA256: 884cfa204b29c0ee3027daec619c3ee0fad4d5098c40342e484b4397d3b523c2
Source Code Git: White-Star UXP
Release Notes

This is a new milestone release. Primary focus for this milestone is web compatibility, in particular Regular Expression extensions, standards compliance issues and further JPEG-XL support. This milestone now offers full coverage of the ECMAScript 2016-2020 JavaScript specifications, with the exception of BigInt primitives.

So, last month Moonchild gave me his blessing to start doing Pale Moon branded versions again, so my current plans are to initially do dual builds.

Starting with the upcoming version 32 release, I will release both White Star and beta branded Pale Moon versions.

The reason for this, is that there has been some minor divergence with the White Star front end, and if there are any issues caused by the reunificiation you can still use the White Star front end if there are problems.

Once any issues are identified and fixed, after a few releases the plan is for Pale Moon builds to be promoted to stable official branding.

At this point, a decision will need to be made to retire the White Star branding, or perhaps keep it for my experimental builds.

What do people think?

So, having gotten 3.3 out, I am taking a look at where things are, where to focus.

A few things I had hoped to get into 3.3 didn't quite make it, specifically visual groupboxes and movable splitbar on iOS and Android.

Android also didn't stabilize quite as well as I had hoped, so these things are still in the plans, but for 3.4 now.

Additionally a feature I hadn't initially planned on did make it into 3.3 in an alpha state, C++ bindings.

Current plans for the C++ bindings are to make std:: string versions of all the API calls, so you can call them with either std:: string or UTF8 char * parameters.  I had held off on this because I struggled to determine what the requirements were for std:: string, but it looks like this support predates C++11 which is the target for the fully functional bindings. So I should be able to implement std:: string versions of the APIs without too much trouble.

Then it is just a matter of figuring out if the miscellaneous API functions should remain in the DW:App singleton class or find homes elsewhere, was hoping to get input from the people who requested the bindings, but one has gone silent and the other seems to have left GitHub where they requested it.

It would also be nice to implement "override detection" that I had attempted at the start.  The information I have gleaned from the internet is that there is no "official" way to do this, there are several implementation specific ways it can be done, but that can be a mess, and not guaranteed to work in the future.  My workaround to this, is fairly simple, but not very elegant. Essentially, on initialization since I don't know if a function will be overridden I connect the signal handler automatically, even if it isn't needed.  If the function isn't overridden our base function will be called the first time this event is triggered, and our base function will remove the unneeded signal.  I left my original work in place as macros that currently always fail, causing this fallback method to work always.   I can use these macros to do implementation specific detection, so the unneeded signals don't get added (and then removed) saving us some unnecessary work... or if in the future there is some new way to do this, it can be done there.

Finally, I need to connect the destructors to DW_SIGNAL_DELETE for cleanup.  The reason I haven't done this yet, is I hadn't decided the best way to do it.  The options are to connect a DW_SIGNAL_DELETE to every widget that has an associated C++ class, and when it is called, call the C++ destructor. This is the most simple way to do it, but most signal heavy, way more intensive than I had ever planned for the Dynamic Windows API.  The other option, is to connect a single DW_SIGNAL_DELETE to the top-level window, and when it closes, iterate through all the child windows calling their C++ destructors.  I might have to try both methods and see which one works better.  There may be other options too that I haven't thought of yet.

So I hope to get the C++ bindings to at least beta (stabilized API) if not all the way to stable for 3.4.

Pierce Ng suggested an API/Signal to allow calls into native code from JavaScript in the HTML widget, so that will probably be in 3.4. The idea was from the Webview project on GitHub which supports Edge and WebKit.  This would cover most of our platforms, but I will need to look into IE fallback support and Chrome support for Android.

If anyone has any other ideas or suggestions for 3.4, I'd love to hear it.