Currently, WebExtensions do not work in SeaMonkey. Per https://wiki.mozilla.org/Add-ons/2017 the existing extensions system is already being phased out, and will be removed in Gecko 57 release. We need to support WebExtensions in SeaMonkey.

This seems like a God-awful development, to me. The rationale for FF adopting WebExtensions, at least as I first assumed, was that it would supposedly make FF more stable. That hasn't happened; or if not, not by much. This was also the rationale for eliminating Flash and Acrobat Reader as browser plugins. Still, if I open FF, and bring up about 20 tabs with lots of JavaScript and content, and leave it for about three days, FF still brings my system to its knees, and goes super slow (Win7 SP1 32-bit). It even happens if NoScript is on, and I bring up a bunch of pages with no JavaScript running. I also tried it in safe mode (i.e., all plugins disabled). Same thing. It happens even though they've invented a new language (Rust) and re-written their rendering engine in it. It was all in vain. It happens even though my CPU threads are not pegged. Maybe it'll go away when they rewrite the rest in Chrome. In the mean time, FF has lost plugin functionality due to becoming ever more a clone of Chrome - a browser FF users are decidedly NOT wishing they were using (Can you say hamburger menu? I knew that you could). Some plugins STILL aren't possible in FF using WebExtensions - and there's not even a decent session manager for it in WebExtensions. IMHO, a true successor to the Netscape legacy should be like 8088 code, FORTRAN, C++ or Win32: much of the oldest 8088 machine language will still run on the fastest PC CPU's today; aside from the OS API. Old C programs run just fine in the newest C++ (although you may need to use a special operative to turn off C++ processing; but often, not). Oldest FORTRAN programs run the latest FORTRAN compilers (don't laugh - it's still taken very seriously for mathematics number crunching). Even today, for as hard as M$ is trying to move away from the Win32 API and "unmanaged" code; Visual Studio still supports it just fine, if you install the right help; and Windows still runs it. Maybe Electrolysis/e10s/multithreading are a bad fit for XUL plugins; but it seems as if FF didn't even try. The rationale for WebExtensions was given here (which I just now found): https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ The thing is, it just dictates that users will not be able to risk a less secure browser to run their favorite extensios. It is suggested that WebExtensions is needed for multiprocess safety, yet it links to a doc that allows devs to see if their XUL plugins can be made multiprocessing safe: https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Working_with_multiprocess_Firefox Now, Needham's agitating for preventing plugins from loading DLL's into FF: https://blog.mozilla.org/addons/2017/01/24/preventing-add-ons-third-party-software-from-loading-dlls-into-firefox/ I think he's just misguided. NONE of these supposed security risks concern me at all!!! I run my browsers in Sandboxie, map out known malware sites with HostsMan using HPHosts definitions, and use WinPatrol to stop unwanted startup apps. I haven't needed an anti-virus in years, and haven't had a virus infection in years. I maintain my family's LAN of 3 PC's, and the last infection we got, was from installing an app from another of us installing some app from some other unknown 3rd-party website (which I would never do). Why is FF being high-handed, and forcing those willing to assume the risks for the sake of backwards compatibility, not to be able to? Why does Mozilla's management let them break things for SeaMonkey as fast as they can, as opposed to asking them to put a little effort into helping you out? (I don't expect you to have an answer for this one, for "political" reasons.) Web developers have gotten yanked around A LOT over this XUL to WebExtensions move. SeaMonkey users have been yanked around over plugins even more. I can't even get any decent SeaMonkey extensions, without using the AMO extension and trolling for old versions on the FF site. Must now SeaMonkey users now also replace all of their plugins, and perhaps lose old ones, perhaps needlessly, because SM devs have drunk deeply of the same mindf**k as FF devs; or could SM devs have a shot at allowing some sort of democracy of plugins? After all, PaleMoon devs just have no use for WebExtensions: https://forum.palemoon.org/viewtopic.php?t=15928 Thus, their ecosystem will continue to update and presumably even produce new XUL plugins. To me, it seems that FF is busy re-writing everything in sight, except the things that might really benefit users the most: a great sandbox and/or rendering in very low priority like Chrome for security; and really studying the slowdown after leaving pages up for a some days (which manifests in less dramatic, but still present, slowdowns sooner). It is as if they want to break backward compatibility on a regular schedule. Remember, the reason for the God-awful-looking Win32 API was because M$ wanted only large corporations with computer programming departments to be able to develop for it (although its popularity, and that of its 64-bit counterpart, is still pretty strong among solo programmers these days, witness WINE, in spite of this). Frequent plugin API changes could have the same effect. I know things are in turmoil for the SeaMonkey development office right now; but I urge you to think twice and see if it is really necessary to follow along blindly, after all.

If we want to have a current ad- and scriptblocker we need to support web extensions. The xul based ones are all broken in 2.57 which is based on ESR 60. Classic extension support will not be dropped and you can, once the support has been ported, install both extension types. Binary plug-ins and add-ons are no longer supported and that is the absolute right thing to do. That said please drop the advocacy in future bugs. We are happy to discuss any issues wrt future developments in the support groups or mozillazine.