The Future of Developing Firefox Add-ons

[therube]

The Future of Developing Firefox Add-ons

"Today we are announcing some major upcoming changes to Firefox add-ons. Our add-on ecosystem has evolved through incremental, organic growth over the years, but there are some modernizations to Firefox that require some foundational changes to support:

Taking advantage of new technologies like Electrolysis and Servo
Protecting users from spyware and adware
Shortening the time it takes to review add-ons

..."

Sounds like a bed of roses .

[barbaz]

All I can say is this had *really* better not be less powerful than the current extensions system in any way... I have extensions that depend on the existing capabilities - it's one thing to have to re-write them, it's quite another to be forced to remove features that are absolutely critical for my Internet browsing.

What does this change mean for SeaMonkey (if different than what it means for Fx)? Is SM going to have to fork large chunks of Firefox code in order to keep going, or are we getting SM 3.0, or nothing special, or...?

[Thrawn]

Don't forget the part about removing the preference that allows you to install unsigned addons. That's a red flag right there. It means that Mozilla retains control of your browser - not an appropriate open-source attitude.

[Giorgio Maone]

WebExtensions API & NoScript

[yes_noscript]

Does that mean what maybe Pale Moon get no more NoScript support then in the future?
Or did you make then a NoScript build too for XPCOM and XUL? Because Pale Moon not remove that.

[barbaz]

@Giorgio: This is good news then, all the functionality of the current extensions API + less breakage with newer Gecko versions

@yes_noscript: Theoretically PaleMoon could support *both* the WebExtensions API and its current system (simultaneously) right?

[yes_noscript]

I have not the technical knowledge but i would say yes.

[Giorgio Maone]

@yes_noscript: Theoretically PaleMoon could support *both* the WebExtensions API and its current system (simultaneously) right?

It could, technically, if it has enough resources to mantain a WebExtensions backport to whataver Gecko version they decide to freeze on.

[yes_noscript]

I get this answer from a guy who help Moonchild and building addons:

Anything is possible theoretically but in order to support WebExtensions it would require implementing this our selves from scratch. Very little if any code from Mozilla and Chrome could be taken as-is. Also we would have to account for lack of e10s somehow.. If our users want this type of thing we would need significant help to do this. In addition to quite a bit of research it would take a lot of man hours.. Maybe it can be looked into when support is complete in Firefox and see what can be done to evaluate it.

However, seeing as we have a very rich repository of extensions already the priority must be with those for the mid-term future.

So lets see what we have in the future

[therube]

Wladimir (Adblock Plus): Missing a rationale for WebExtensions

[Giorgio Maone]

Wladimir (Adblock Plus): Missing a rationale for WebExtensions

One rationale is, at least in my view, that the Chrome extensions API, with all its defects and limitations that Mozilla vows to fix and overcome in time (for instance by quick allmighty prototyping through native.js), has been designed from scratch to work within a multi-process browser architecture. It only makes sense that we don't reinvent the wheel here, since the main, most useful (both for security and perceived performance) but also most painful change we're undergoing through is the transition to Electrolysis.

As an aside, while I wouldn't emphasize a "write once run everywhere" promise which cannot be realistically keep, I believe relying on the same architectural abstractions and on similar, even though not identical, (subsets of) APIs surely makes developers' life easier and the ROI of acquiring browser add-ons development skills higher.

[therube]

Please read and comment:

https://discourse.mozilla-community.org/t/proposal-native-js-to-embrace-extend-the-webextensions-api/3457

I found it humorous that you need to allow JavaScript to see it .

[al_9x]

Classic Theme Restorer is probably the best canary in the coal mine for these changes, because it radically unfucks tweaks post australis ui, through xul, css and javascript hacks that mozilla is not likely to acknowledge as needed (that would mean admitting they've been making things worse for years)

The author of CTR is not optimistic about its future:

https://hackademix.net/2015/08/22/webex ... -noscript/
https://hackademix.net/2015/08/26/webextensions-faq/
https://discourse.mozilla-community.org ... s-api/3457

According to Girogio Maone (noscript) Mozilla is working (at least with him) to meet the needs of add-ons that need more than WebExtensions. Would it be possible for you to link up with whoever he's working with to make sure CTR requirements are addressed?

I doubt CTR will continue to exists the way it does now. Maybe we will at least be able to set / modify css code for UI elements, maybe not, but the whole point of Mozillas decision to drop XUL would not make any sense, if we still could do same UI tweaks currently possible.
Lets see what Mozilla comes up with in the next months.

Correct me if I'm wrong, but "NoScript" or "Adblock" are mostly web filters, that manage web content between users (what they see or execute) and servers (what is offered [html, scripts, images, videos...]). They do not modify the browser ui, only the web content, right? So you can not compare those to CTR or other add-ons that modify buttons, toolbars or icons etc..

If you look at what is currently possible with Google Chrome or Opera, you see nothing is possible. There are no add-ons that modify/move/remove default menus, menuitems, toolbar buttons, icons or toolbars*, because browser developers do not want you to do thise. If Firefox goes the same way, such level of customization won't be possible either.

* Google Chrome only allows to change main background images which can be compared to Firefox lw-themes and Opera "themes" allow to change new tab pages background and preferences background, what is joke imo.

@Giorio Does your optimism extend to CTR? If so, on what basis?

[yes_noscript]

Today the CipherFox developer stop (temporary) support Firefox and develope now only for Pale Moon and include full Pale Moon support with the new version which released today.
I hope more addon devs make this step.

Here the post from him:

CipherFox developer here.

Sorry for my delay on this, but Pale Moon support has now been added to CipherFox:
https://github.com/gavinhungry/cipherfo ... 5d2383d8ed
https://github.com/gavinhungry/cipherfo ... 1f919a4ebe

I've submitted version 3.11.0 to AMO with these changes (pending review). If you'd rather not wait you can grab it from here:
https://addons.mozilla.org/firefox/down ... 1.0-fx.xpi

With the soon-deprecation of XUL in Firefox, Pale Moon is now the main supported target application for CipherFox, at least in it's current form. If CipherFox can ever be made available on post-XUL versions of Firefox, I will likely maintain both.

[therube]

(Links mangled by the board, but they're here: http://forum.palemoon.org/viewtopic.php?p=62575#p62575.)