Open Bug 1320556 (SeaMonkeyWebExtensions) Opened 7 years ago Updated 1 month ago

Tracking bug for WebExtensions support in SeaMonkey

Categories

(SeaMonkey :: General, task)

task
Not set
major

Tracking

(Not tracked)

People

(Reporter: kevink9876543, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: meta)

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.
Depends on: 1370302
Alias: SeaMonkeyWebExtensions
Severity: normal → major
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.
Depends on: 1555116
Type: defect → task

As for Seamonkey 2.57 ( 20210319120003 / http://www.wg9s.com/comm-257/ ):
Web-Extensions look better than before, but noscript-11.2.3.xpi shows no icon and the config page looks funny.
Same for uBlock0_1.34.0.firefox.xpi, shows no icon and funny looking config page.
(Those are the only two I really care about)
If I have to ask the developers of these extensions, just say - currently suspecting Seamonkey : ).

2.57 still needs extensive work to make this happen. Web extensions are just awful. You basically need to put support for all the apis in both the frontend and the backend. backend is there mostly since 2.53 but frontend not.

During October and November this year something arised: A HUGE amount of sites stop working with Seamoney 2.53 (including latest builds). Whether is is nvidia forums, gitlab.com, linkedin, discord and so on... the number of sites are rising so fast I will be forced to switch away from Seamonkey. And I've been with it since Netscape 0.9, Mozilla suite and now Seamonkey - i.e. way above 25 years.
All those sites work with Seamonkey 2.57 (build from http://www.wg9s.com/) - but without noscript and ublock the internet is unbearable, and to quite some extend unusable.
Of course I tried a blank profile with Seamonkey 2.53, and a fresh installation with the latest official version + blank profile.
Is there a way to sponsor ONLY Seamonkey and nothing else to get this problem fixed soon? Or is it already fixed and I have to do some steps?
Else I have no choice but to switch to Firefox/Thunderbird, simply 'cause Seamonkey does not work any more - literally.

2.57 will not fix these sites. They need support for later and sometimes still experimental js and css constructs. Updates are done as time permits. For discussing such issues please use the support groups.

Speaking of WebExtensions frontend, Waterfox Classic supports both XUL and WebExtensions add-ons. Could parts of its code be used to help with this issue? Or SeaMonkey codebase is too different?

Waterfox Classic basically uses the standard Firefox browser frontend code. This still works because I test it frequently with a Firefox built from our codebase. SeaMonkey is different because you not only deal with the browser but also with mail and the other components. The so called webext api was never designed for anything like this. Thunderbird now has a mail api implementation but basically from scratch.
This bug moves only forward if some people invest some time. First is that the tabtracker api needs to be implemented in the frontend. If I or IanN do it in earnest you won't see any other progress or releases for a long time. So piecemeal progress as in now. Can't be helped.

You need to log in before you can comment on or make changes to this bug.