Firefox to deprecate XUL

[Shadoefax]

Well, it looks like Mozilla finally did it. I've never seen an organization so hell-bent on self-destruction. Mozilla announced last Friday (8/21/15) that it will be phasing out XUL and XBL implementation and disallowing sdk-built extensions access to chrome. In its place they will offer an alternative WebExtensions API. Exactly how this will affect developers is not certain just yet, but from all of the comments I've read so far, the future looks glum.

This means that many extensions will have to be re-developed and many simply cannot be written with the limited API. I've been developing extensions for Firefox for over a decade and all were written in the XUL/JavaScript framework. I will not rewrite them from scratch, and will simply remove them from AMO when the XUL deprecation occurs.

Most of my extensions work (or have worked in previous versions) with Pale Moon and would like to continue developing/maintaining them.

A couple of questions:

1. What is the latest version of Firefox that extensions written for it will work with Pale Moon?
2. Is this the official repository for Pale Moon extensions? How would one go about submitting extensions there for listing?

I'm sure that if Mozilla carries out its threats, there will be many other developers that will move to PM.

[Moonchild]

1. In general, our front-end extension compatibility is equal to the FF24ESR series, but with a few differences, e.g. bindings to content needing to specify that they are allowed to bind to untrusted content, as a security measure.
Later FF versions of extensions may also work, as long as they don't specifically break compatibility and don't use js or front-end (specifically: Australis/customizableui) features that haven't been implemented in Pale Moon (yet).

2. We're working on getting a second generation site up for extensions, but for the time being the best way to go about it, especially if you have many extensions you want to list/include, is to talk to the addons site maintainer Matt A Tobin.

[dark_moon]

In the NoScript i get this question:
Theoretically PaleMoon could support *both* the WebExtensions API and its current system (simultaneously) right?

What can you say about this, Moonchild?

[New Tobin Paradigm]

In the NoScript i get this question:
Theoretically PaleMoon could support *both* the WebExtensions API and its current system (simultaneously) right?

What can you say about this, Moonchild?

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.

[SvenG]

I've been developing extensions for Firefox for over a decade and all were written in the XUL/JavaScript framework.

You did FEBE? Cool, welcome on Board

[__Vano]

The reasoning that the vast insight into (and the resulting promises about) the browser's internals prevents them from changing said internals, making them stagnant, is sound. (I didn't buy the feeble "security" and "performance" claims)

What they are doing now is basically struggling to work out some other browser model that would give enough customizability while being disjoint from implementation (the current implementation, at least), providing them the freedom to do the major changes that have accumulated over time.

Yes, the two goals are diametrically opposite. Their only hope is that there exists a realistically sized set of "abstracted" features that will suffice for the vast majority of extensions.

[Moonchild]

I'm sorry but the realistic side of things is that XUL, bootstrap and SDK alike are being phased out by Mozilla. There is no "other framework" apart from a limited API that is being copied from Chrome. Mozilla is becoming just the glue - and you can't really interact with glue because it has nothing to interact with.

Mind you, I get it: making things modular and preventing extensibility makes it easier to maintain. But that is not what the users want -- they want the customizability and flexibility that has always been the major strength of the XUL framework (and why Pale Moon won't deprecate it).

Their only hope is that there exists a realistically sized set of "abstracted" features that will suffice for the vast majority of extensions.

They don't have this, and they know it. WebExtensions don't have a broad enough feature set because the API is, by design, cross-device and cross-platform, meaning what is available is necessarily the lowest common denominator of all targets -- but it doesn't stop there; what potential there is, isn't properly filled even. From the outset, Mozilla has known this and has made clear they would be forced to create additional APIs for specific tasks, and reserving that work for hand-picked extensions of their choosing. Something as simple as content manipulation (e.g. Ad Blocking) can't be done without extra functions; that spells plenty of limits otherwise (unless you just want UI gadgets to launch/navigate to specific sites... you don't need an extension for that).

Being able to create extensions that interact natively with the browser's interface code and inner workings is what gives them power. Layers of abstraction will prevent that kind of interaction, especially if trated as untrusted code instead of trusted code...

[Shadoefax]

Strictly speaking, the deprecation of XUL itself is not the true problem. XUL is just another (albeit, perhaps superior) form of HTML. It is a relatively trivial matter to convert a window laid out in XUL into one laid out in HTML. What makes XUL powerful is the ability to use XPCOM. Mozilla is replacing the XUL/XPCOM model with the HTML/WebExtensions model. WebExtensions are merely children's toys used to build simple eye candy extensions as opposed to powerful, truly useful, robust browser extensions. If XPCOM is an Erector Set, WebExtensions are just simple Lego bricks.

What concerns me most is who will support and develop the XUL/XPCOM framework when Mozilla finally leaves it? There are currently over 3,000 open bugs for XUL in Bugzilla (dating as far back as 2001). Mozilla created XUL/XPCOM to begin with and I seriously doubt they will continue to maintain it once it's deprecated. How long can Pale Moon continue to support it when nobody is maintaining it?

[New Tobin Paradigm]

We are maintaining it and we will continue to do so indefinitely. Also, just because there is a bug in bugzilla doesn't mean it is actually a problem. Likely a great number of those are DUPLICATEs, WONTFIXes, and WORKSFORME.. Especially the older ones. Also, some are also INVALID because they cite problems in products that don't exist anymore like XUL based Fennec.

Bug triage seems hit or miss at various points in the history of Mozilla and people just blindly file bugs and then never do anything again.. This has clear evidenced here on this very forum.. People don't search or read.. uhh.. EVER. Just create a new topic and never visit it again.

Also, you have heard of.. "Pale Moon is not Firefox and never will be again" right? In addition, as a matter of history.. Mozilla did not create XPCOM or XUL.. Netscape did and while much of the core at the time Mozilla was formed was made up of Netscape staff that didn't last too much past say 2002 when Netscape effectively died.