Will Pale Moon support WebExtensions?

[Moonchild]

WebExtensions are the (chrome-sourced) type of extensions to web browsers using a very limited subset of APIs available through a framework. You can compare them with Jetpack/SDK extensions, but then without having the option to even call into lower level functions.

Pale Moon (as an application) will likely never support WebExtensions, even if we would switch to a platform that technically supports its use, because:

• Having XUL/overlay, bootstrapped and SDK/PMKit extensions already provides everything any extension developer could want or need for extension development, and then some. Adding a 4th technology to that line-up that is radically different and more limited in what it can offer by design is a maintenance nightmare and time-sink we simply don't want in our project.
• Pale Moon's front-end doesn't use UI controls or layout that allows html-based widgets (the only way for WebExtensions to interface) to be inserted. As such, it would require a (messy) compatibility layer to enable insertion into our XUL-based UI, and likely will cause many many bugs. Even if a new platform in the future might theoretically allow the use of WebExtensions, Pale Moon's application code will not.
• WebExtensions are too restrictive for anything but the most basic tools and will not, ever, allow true extension of the browser's functionality as a result. This makes the technology used for it undesirable for Pale Moon since it will, by design, fall short from day 1.

[Gorlash]

I am *so* glad to hear (well, read) that !!!
I've moved to PM specifically to get away from the crippled modern stuff that FF is glorying in...
PM is perfect !!

[palacs]

So glad to hear that.

I hope Pale Moon will stay on the same track as it is now and will never get ruined by useless modern idealistic anti-features like Firefox and Chrome.

[rafaelgomesxyz]

This sucks for developers. Instead of developing a single extension that works on all browsers, you have to keep converting your code to work with specific browsers, which is not ideal. At least I don't have to modify my extensions that much because I use a compatibility layer with the SDK API that mocks the browser namespace, but still. It's the same thing with Safari. I wish all browsers would just support the same standard to make our lives easier.

[Moonchild]

Think about that approach for a moment, and then realize that you can only target the smallest common denominator between browsers which will be the content they display.
You will never be able to have extensions that actually extend browser features because they are, by definition, unique to the different browsers. So you will only be able to do content manipulation. That is a small part of what our extensions can do now.

[vannilla]

This sucks for developers. Instead of developing a single extension that works on all browsers, you have to keep converting your code to work with specific browsers, which is not ideal. At least I don't have to modify my extensions that much because I use a compatibility layer with the SDK API that mocks the browser namespace, but still. It's the same thing with Safari. I wish all browsers would just support the same standard to make our lives easier.

As a developer I believe it's better to give users more power to extend the browser (that's what extensions are for) than make life easier for developers.
The latter folks are usually a very small subset of the people dealing with extensions, and losing features just to make life easier for that 1% is not worth it.

[01101001b]

I wish all browsers would just support the same standard to make our lives easier.

That's the price of diversity and choice, I guess, but I get your point

[Moonchild]

I wish all browsers would just support the same standard to make our lives easier.

That's the price of diversity and choice, I guess, but I get your point

I don't get that point. How would it make the lives of the end-users easier?

[01101001b]

I wish all browsers would just support the same standard to make our lives easier.

That's the price of diversity and choice, I guess, but I get your point

I don't get that point. How would it make the lives of the end-users easier?

Of course you don't, my friend, because you are thinking about end-users' lives but he is referring to developers'

[Moonchild]

Right you are.

I still don't get the point why this would have to be an issue. If you are a developer of extensions targeting different applications, you can't expect those applications to take the exact same extension code and be happy with it -- unless of course you are really thinking that browser extensions should be akin to web page scripts and nothing more (which is the point I touched on before: content manipulation only). But in that case, why make extensions to begin with? There are these wonderful things like GreaseMonkey etc. that already let you create content manipulation scripts.

[01101001b]

I still don't get the point why this would have to be an issue. If you are a developer [...] you can't expect those applications to take the exact same extension code and be happy with it -- [...] There are these wonderful things like GreaseMonkey etc. that already let you create content manipulation scripts.

A good sound point. Totally agreed.

[Isengrim]

There are these wonderful things like GreaseMonkey etc. that already let you create content manipulation scripts.

+1

Although, I think one counter argument would be that userscripts don't allow for much in the way of configuration, which is where the browser APIs come in to play.

[Moonchild]

But browser APIs are, by definition, browser-specific.

[rafaelgomesxyz]

As a developer I believe it's better to give users more power to extend the browser (that's what extensions are for) than make life easier for developers.
The latter folks are usually a very small subset of the people dealing with extensions, and losing features just to make life easier for that 1% is not worth it.

Why does it have to be exclusive, though? Can't we have both?

Right you are.

I still don't get the point why this would have to be an issue. If you are a developer of extensions targeting different applications, you can't expect those applications to take the exact same extension code and be happy with it -- unless of course you are really thinking that browser extensions should be akin to web page scripts and nothing more (which is the point I touched on before: content manipulation only). But in that case, why make extensions to begin with? There are these wonderful things like GreaseMonkey etc. that already let you create content manipulation scripts.

Yes, I'm mostly thinking about content manipulation, because that's what my extension does. Greasemonkey and the other script managers are much more limited than WebExtensions, and can lead to really bad performance with large scripts. My extension used to be a script, but as it grew, it reached a point where I had no choice but to upgrade it to a WebExtension to access more privileged APIs, and it became incredibly faster when I did that. I assume this is the same reason why Enhanced Steam, one of the most popular content manipulation extensions, also started as a script but moved to a WebExtension eventually.

But still, isn't that what standards are for? Taking the exact same generic code and specializing it internally? When I call `browser.storage.set()`, for example, I'm telling the browser that I want to save something in the storage of the extension. Of course it will be implemented differently in each browser, but they all understand what I want.

But browser APIs are, by definition, browser-specific.

Not the ones being standardized by the Browser Extension W3C group.

Anyway, I get that WebExtensions are limited, and I understand if they won't be implemented on Pale Moon because of the maintenance required, but for some cases, they are enough. Not that it matters to me now anyway, since I've already created my compatibility layer using the SDK API, so for as long as the SDK API is supported, my extension will run fine.

Also, sorry for the late reply, I forget about forums sometimes.

[vannilla]

Why does it have to be exclusive, though? Can't we have both?

It's not always possible.
Sometimes, making sure the end user gets the most out of it can negatively impact a developer's experience.

<snip>

The thing is, even if the API is standardized, it does not mean it's better or complete.
The standard describing WebExtension is more or less a subset of what Toolkit extensions can do.
So, what happens with the rest of the Toolkit API? Is it useless? It can't be, because it's more powerful.
So standards for application-specific code mean nothing. In particular when it deals with manipulation of the user interface.
With WebExtension you don't have to touch anything: all you have is a burger menu containing the icon for your extension (it was like this last time I checked, at least), with Toolkit extensions you can have a button on any toolbar, make a custom toolbar, make a custom menu... it's certainly better for UI customization.
You can't standardize this, because some browsers might want to use toolbars, while some others are fine with the burger menu.
UI composition is an integral part of an application branding, and a single appearance can't be forced upon everyone.

[New Tobin Paradigm]

Why is this discussion going on. The capability to run old and insecure webextensions was removed from the codebase and will NOT be coming back. I'll quit first.