The future between Pale Moon and WebExtensions

[billmcct]

@frostknight,
It has been fixed since yesterday morning. I PMed @RealityRipple to let him know.
Myself and others reported it to Comcast and they fixed it a lot faster than I thought they would.
However I still say Comcast sucks.

[Moonchild]

Since I have some time to actually address the concerns of OP before this went onto a tangent:

[*]very quickly, add-on developers realized that anything they did could break anything else in the system, including other add-ons and Firefox itself, and they often had no way to prevent this

[*]similarly, anything Firefox developers did could break add-ons, and they often had no way to prevent this

I could see that, since Firefox rarely (if ever) crashes, due to an add-on, during the time of 2019-2025 where they fully migrated to WebExtensions(Couldn't find a single incident between this time that crashed the entire browser.

What you're talking about and the quotes are two entirely different things. The quote is primarily talking about the browser/UI functionality not working as it should or at all. Not necessarily the browser application crashing.
Of course the amount of breakage is reduced when you don't actually allow extensions to touch UI code any longer, and restrict them to (as the name implies) Web content. WebExtensions are not allowed to make fundamental changes to the browser front-end like XUL extensions are (and as a result they can't extend the browser itself). Even more so, more advanced interactions with non-web-content requires tailor-made APIs for WebExtensions specifically to work, as opposed to getting the same power and capabilities native front-end code has.

As for changes in Firefox breaking add-ons... that wasn't anything new before, and hasn't changed since. Extensions need to be maintained, regardless of their type, unless they are overly simple things that could be solved likely with a user script or bookmarklet instead of an extension. Of course having removed all interaction with browser internals, it solved some problems - but at the cost of a lot of power for extensions. Basically neutering the extension capabilities so they could not possibly touch parts that influenced the UI/browser code, would prevent issues by simply disallowing extensions to do much of anything.

Maintainability could have been improved if they supplied a stable abstraction layer -- which was attempted with the add-on SDK/jetpack. But the problem there was that Mozilla quickly realized that it meant they would actually have to maintain the SDK-to-chrome bridge, which would cost more money. Another issue with it was that it was poorly organized and it was not feature-stable, which in turn meant they weren't actually solving any of the problems with it.

Pale Moon, on the other hand, suffers a lot of crashes, like what happens from the infamous NoScript add-on, DeCDN crashed the browser on an Image-heavy page, and many more undocumented crashes by some add-on on Pale Moon.

The fact that an extension exposed something in the browser/platform, doesn't necessarily mean that the nature of XUL extensions is so fundamentally flawed that it needs to be done away with. That's an extremist black&white view on software development. If you want to dredge up NoScript yet again, I kindly point you to the door. I've extensively and repeatedly explained the exact issues with it. Yes, it's a bad extension, yes it causing issues is a result of extensions being powerful and potentially deep-reaching. No that's not a bug, it's actually a feature of XUL extensibility.

If you were writing XUL-based add-ons, you quickly realized that preventing it from breaking stuff was… complicated. Several add-ons could modify the same part of the user interface, resulting in odd results. Several add-ons could accidentally inject JavaScript functions with the same name, or with the same name as an existing function, causing all sorts of breakages.

This issue, if not being seen right now, it could be more present in later years, when Pale moon addons gets updated with more and more lines of codes to accommodate to today's modern

The main argument against this is the fact that there were made many thousands of add-ons by non-developers and hobbyists that would happily all coexist in the add-on ecosystems without major interference or stability issues.

Some critical things that were not touched in the post I think should be highlighted: One was the obvious reasoning Firefox wanted to do away with both full-application impacting extensions and complete theme overhauls at the same time, and that was to push a brand-first policy: don't allow extensions or themes to significantly alter or customize the way the browser looks or operates. Another was the obvious desire to make a single walled ecosystem for all browser extensions of multiple vendors - one store to rule them all.
Then there's the problem that WebExtensions exist in a grey area that both is and isn't web content, by hacking in HTML controls into the interface. Chrome has less risk of this causing problems because the UI is (AFAIK) native code, not built on web technologies like Firefox is. Either way, to this day, WebExtensions are causing serious security risks beyond poor interaction with a UI or each other, that would not exist if add-ons were not forced into an HTML subcontext of an extensible markup language. e.g. CVE-2018-5152 CVE-2020-6809 CVE-2020-15655 CVE-2020-35111 CVE-2021-43540 CVE-2022-34471 CVE-2023-32210 CVE-2024-7525 CVE-2024-11696 CVE-2025-1936 and multiple issues with thread safety and CSP implementation bugs...

[frostknight]

If you want to dredge up NoScript yet again, I kindly point you to the door. I've extensively and repeatedly explained the exact issues with it. Yes, it's a bad extension, yes it causing issues is a result of extensions being powerful and potentially deep-reaching. No that's not a bug, it's actually a feature of XUL extensibility.

Truthfully, I used to be so into noscript, some would say it was like religious following.

If I can move on from it, I don't see why others can't.

I mean... ematrix is a thing, so... yeah.

[Shadow]

Utube redirects to "https://utube.realityripple.com/".

Is that meant to be found? Can't find a "here's this cool thing" link to it with the expected explanation.

[billmcct]

Utube redirects to "https://utube.realityripple.com/".

Is that meant to be found? Can't find a "here's this cool thing" link to it with the expected explanation.

Not sure what your asking. If you play a video on Utube it will redirect to:
https://realityripple.com/Software/XUL/uTube/play.html
or
https://utube.realityripple.com/XXXXXXXXXXXX

[Shadow]

Not sure what your asking. If you play a video on Utube it will redirect to:
https://realityripple.com/Software/XUL/uTube/play.html
or
https://utube.realityripple.com/XXXXXXXXXXXX

That's it basically. Didn't know what it was. Was thinking more broadly, along the lines of an Invidious type thing.

Are there added privacy benefits using this way too?

[RealityRipple]

Not sure what your asking. If you play a video on Utube it will redirect to:
https://realityripple.com/Software/XUL/uTube/play.html
or
https://utube.realityripple.com/XXXXXXXXXXXX

That's it basically. Didn't know what it was. Was thinking more broadly, along the lines of an Invidious type thing.

Are there added privacy benefits using this way too?

https://realityripple.com/Software/XUL/uTube/.

It's an embedded video instead of on the official site, using the "youtube-nocookie.com" domain (by default). Its main purpose is to cut out the YT interface and provide just the video, with the added benefit of ads not playing because Google never got around to making ads work in embeds.

[Bilbo47]

"RECORD_TOO_LONG" can happen if the SSL port is serving unencrypted http instead of providing an SSL handshake...

all three people that reported HTTPS access problems to my site are on Xfinity. They might be mangling the certificate...

By that do you mean MitM Machine in the Middle, which decrypts and (attempts to) re-encrypt all traffic it sees?

Agree stay away from Comcast / Xfinity

[RealityRipple]

"RECORD_TOO_LONG" can happen if the SSL port is serving unencrypted http instead of providing an SSL handshake...

all three people that reported HTTPS access problems to my site are on Xfinity. They might be mangling the certificate...

By that do you mean MitM Machine in the Middle, which decrypts and (attempts to) re-encrypt all traffic it sees?

Agree stay away from Comcast / Xfinity

I think what actually happened is it was serving an HTTP error message... but not actually checking to see if it was over HTTPS when it served it.

[Tharthan]

RealityRipple, I'm having the same problem. It went away yesterday and earlier today, but it's back again.

My Internet provider is Cox Communications.

I like your uTube extension and always have it enabled, so this issue is a real pain in the neck.

[RealityRipple]

RealityRipple, I'm having the same problem. It went away yesterday and earlier today, but it's back again.

My Internet provider is Cox Communications.

I like your uTube extension and always have it enabled, so this issue is a real pain in the neck.

Not much I can do on my end; you need to determine if it's your ISP or if it's an anti-virus that's doing the blocking, then report it as a false positive.

[UCyborg]

Probably the biggest issue is that the non web extensions have fallen into obscurity and there's no interested parties willing to develop them.

[frostknight]

Probably the biggest issue is that the non web extensions have fallen into obscurity and there's no interested parties willing to develop them.

I wouldn't say no one, I would say *MOST* people.

Otherwise, no extensions would be worked on anymore period even the ones currently being worked on by people here.

[Basilisk-Dev]

Why are we even wasting time discussing this? The Pale Moon project has made it very clear that WebExtensions are not a technology that they want to support. I'd imagine most members of the community here agree with that decision.

If you want WebExtensions then use Firefox/LibreWolf/Waterfox/Chrome/Chromium/Orion/etc.

[Moonchild]

The Pale Moon project has made it very clear that WebExtensions are not a technology that they want to support.

As it is, it's not even possible for our platform to support them, period. And if someone wanted to have this support they would have a pretty big mountain to climb (and many dozens of security issues to address surrounding WebExtensions as well). Basically, that ship has sailed years ago. If you want functionality a WebExtension provides, then do what 10000+ hobbyists did in the past and do a bit of research and make your own Pale Moon/XUL extension. It's not rocket science, but you have to be willing to learn some new things.

[UCyborg]

webextensionapocalypse hit a good number of useful-to-me extensions, there's uBlock, there's no user style manager that can stomach current user style format, GreaseMonkey has unexplainable bugs, last compatible Reddit Enhancement Suite is an old buggy version from 2017, no decent extension for integration with KeePass, nothing that supports entry of OTP codes at least.

One of my co-workers that works as a programmer told me once that browser customizations aren't worth the bother to him, everything's too much of the moving target. I tend to agree with him more as the time passes.

[frostknight]

As it is, it's not even possible for our platform to support them, period.

So basically EVEN if you wanted to, you couldn't SUPPORT them.

That sounds like what you are saying, am I right?

And yeah, they have privacy issues which is why Google wanted mozilla to switch to them.

Such an insane thing to do... trusting "Google" for such things is almost as stupid as trusting microsoft for security/privacy.

[Moonchild]

So basically EVEN if you wanted to, you couldn't SUPPORT them.

Unnecessary google rant snipped

I was talking about platform support, as in, not being able to run them/have them interface with the browser. Not "providing support for them"

[UCyborg]

Mozilla used to have both have XUL and web extensions in the browser. That code is underdeveloped, but still lives in roytam1's Serpent/Basilisk. I got KeePassXC Browser version 1.9.3 working on it. Needed some minor tweaks and polyfill for navigator.locks. It gets complicated with newer versions, needing managed storage something...that web extension support is more of an alpha than something usable in the grand scheme. Latest uBlock and Redddit Enhancement Suite...nah. Bleh!

[moonbat]

web extension support is more of an alpha than something usable in the grand scheme.

It's pointless to have, just another compatibility layer like their earlier attempts with Jetpack and Addon SDK, plus it would introduce a whole new attack surface if attempted here. I wonder if one could use AI code generators to convert web extensions to XUL ones though.