emacs on xul
In all seriousness though I have a hard time imagining why anyone would want this ... both from a developer standpoint and a user standpoint. The recent change history is a bunch of "most of ABC other Mozilla product's code has been pulled in for X.Y.Z version, go read those notes to see what is new" and describes cherry-picking bugfixes from arbitrary versions of Firefox (60, 72, ...?)
Sounds like an absolute maintenance nightmare (or perhaps a labor of masochistic love, depending on how you look at it) of constantly cherry picking other upstream stuff into one single app for what looks like a relatively small gain. If you had no choice (ie, what linux distribution maintainers spend a lot of time on) sure, go for it, but I can use Firefox, Thunderbird, etc... as standalone apps and still have them connected using my local OS and regular old open web technologies.
Wow, that’s... something. Keeping a browser engine of that size maintained independently is going to be quite a task.
Plus there are a bunch of CSS improvements and the like in the last five years. If you don’t keep up with the competition your users are going to see broken sites eventually.
I don't really use it often but I love that it still comes with Composer for WYSIWYG html. It's been a while but when I used it a lot about 5-7 years ago it wrote really clean, standard compliant html which made it great for quickly prototyping look and feel before diving into writing any code for new pages/sites.
Having used the stock Slackware version, which is usually just a bit behind, I'm excited to see what "our biggest release in a few years and incorporates many changes and fixes from the underlying platform code" looks like!
I tried it for the first time a few weeks ago (I never do web/HTML stuff). Seamonkey Composer crashed when I tried inserting a <video> element.
> Having used the stock Slackware version, which is usually just a bit behind, I'm excited to see what "our biggest release in a few years and incorporates many changes and fixes from the underlying platform code" looks like!
According to the release notes (http://www.seamonkey-project.org/releases/seamonkey2.53.1/) it is mainly features removal and breakage :-/ The least one can cay is that they are not chatty about the positive changes and features those underlying changes may have brought.
And yes, I was mildly disappointed when I downloaded and ran this as I saw no real visual difference or changes to the UI and preferences.
So I guess Composer is not much of an option for "real" work these days. Still cool to see an alternative browser out there that's at least mostly capable of handling the "modern" web...
EDIT: I was able to convert xul/xpi addons with: https://addonconverter.fotokraina.com/ which is quite awesome. Info here: http://forums.mozillazine.org/viewtopic.php?f=40&t=2834855
These two objectives pull in opposite directions. The more you get of one, the less you're going to get of the other.
https://github.com/mozilla/firefox-browser-architecture/blob...
The short version is that XUL is a mozilla-specific implementation of functionality that can be accomplished with standard html5/CSS/etc., and thus using specifically XUL to handle the UI is inefficient from a developer standpoint, which can also introduce bugs, etc. as developers are forced to work on/use a technology with which they're not familiar.
XUL is being replaced with (was replaced with?) the standard HTML5 engine, which is continually being improved, updated, secured, optimized, etc. IIRC, there's no reason that an extension couldn't do what it did in XUL, so the likelihood is that the lack of those extensions isn't directly related to Mozilla removing XUL, but rather extension developers re-implementing their extensions in HTML5 for Chrome, which is a vastly more common platform for browser extensions in my experience, instead of re-implementing their extensions in HTML5 for Firefox.
XUL extensions were given full access to the XUL DOM for the entire browser, whereas WebExtensions are limited in their sandbox to known extension points rather than having full HTML DOM access to the entire browser.
Also, while WebExtensions still have access to messaging channels to websites/native code/outside applications, it is indirect (and permissions/sandbox mediated). XUL extensions' XPCOM (like Microsoft's COM) gave a much direct path both in to the HTML DOM of individual websites and outward for native platform code to be written in languages like C/C++.
(All of the above of which include additional reasons why XUL/XPCOM may be security liabilities if your goal is a secure browser: free reign of the browser DOM, website DOM, and easier access to native code.)
The XUL-webextension transition resulted in a huge loss of API surface. This cost us vim keybindings, tree style tabs, the ability to modify the new tab page, and probably some other things that I'm forgetting. While they eventually added some replacements, it's still not 100% back to where it was (ex. tree style tabs now works, but can't hide the original tab bar).
(Confusingly, there were many more versions of Netscape after 4, but Mozilla Suite didn't really derive from them. Netscape 6 and 7 were just contemporary versions of Mozilla Suite with some Netscape badging slapped on. Netscape 8 was based on early versions of Firefox, dropped the other non-browser "suite" components, and was only released for Windows. Netscape 9 was also a browser-only thing, but went back to being cross-platform.)
I think it would be just slightly more accurate to say, that it didn't derive from them at all, as the original Netscape codebase was scrapped.
https://en.wikipedia.org/wiki/History_of_Mozilla_Application...
[1] There's a few more directories that are split out of mailnews, due more to historical reasons than any sane code split.
Seamonkey
Netscape Mail -<
ThunderbirdTrojan:Win32/Detplock
Alert level: Severe
Status: Active
Category: Trojan
Details: This program is dangerous and executes commands from an attacker.