Why Did Mozilla Remove XUL Add-ons?
Moderators: trava90, athenian200
-
- Hobby Astronomer
- Posts: 28
- Joined: 2016-11-30, 08:28
Why Did Mozilla Remove XUL Add-ons?
I just read this post from a Mozilla Developer
https://yoric.github.io/post/why-did-mo ... ul-addons/
And after reading this I was much more thankful that you still remaining the development of XUL. If I understand this right, they thought it is impossible to go on but you do.
I find it interessting to know why they had remove this and why they decide to be closer with chromium. And anyhow some interessting details about programming interfaces.
https://yoric.github.io/post/why-did-mo ... ul-addons/
And after reading this I was much more thankful that you still remaining the development of XUL. If I understand this right, they thought it is impossible to go on but you do.
I find it interessting to know why they had remove this and why they decide to be closer with chromium. And anyhow some interessting details about programming interfaces.
-
- Pale Moon guru
- Posts: 35637
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: Why Did Mozilla Remove XUL Add-ons?
Basically it boiled down to: Mozilla wanted strict control over what could be done with and to Firefox. Extensions were too powerful, and they wanted to have control over the browser's core, not letting the user adapt it to their desires. We couldn't have extensions (or god forbid full themes) changing the way Firefox looked and worked from the corporate-approved template, now could we?
Of course this was all clad in "security" but ask yourself: have WebExtensions been more secure? How often have you seen security bugs dealing with XPCOM or the XUL extension system itself? Compared to WebExtensions sec bugs that's almost nothing.
Of course the keywords in the article are that they wanted to "try new things", and the "oh, and by the way" point as if that wasn't the main reason
The real drivers behind it, in my opinion, were:
Of course this was all clad in "security" but ask yourself: have WebExtensions been more secure? How often have you seen security bugs dealing with XPCOM or the XUL extension system itself? Compared to WebExtensions sec bugs that's almost nothing.
Of course the keywords in the article are that they wanted to "try new things", and the "oh, and by the way" point as if that wasn't the main reason
The real drivers behind it, in my opinion, were:
- Not wanting to have to vet extensions (which is why there are so many garbage and insecure WEs out there). It directly ate into the profit margin, after all.
- The fact that they wanted to attempt to have a unified extension system with Chrome to make it "easier for extension writers to write cross-browser extensions", which was even given as the main reason when they started this but somehow mysteriously absent from the linked article (unless I completely missed it somewhere?). Probably because it was a pipe dream?
- As stated wanting to have strict control over the look and feel of the browser, and wanting extensions to be mostly limited to manipulating web content, not actually being browser extensions.
- Extension maintenance was supposedly "undoable" for extension developers. regardless of the fact that thousands of hobbyists easily did this in their spare time or a few lost hours every release.*
- They wanted Electrolysis (multi-process), and adopt more of Chrome because "Chrome felt snappier". Wanting incompatible tech changes meant they had to do the extension system more like Chrome as well, even if WEs are fundamentally incompatible with how the XUL UI accepts additional UI content. Firefox's front-end is still XUL-based, to this day. Don't let the lack of browser.xul fool you; the namespace for the browser UI is still XUL.
- Permissions system, or how presenting a few mobile-like permissions choices to the user is never a replacement for expert vetting.
- Rust, because that worked so well that they sacked the entire servo team in 2020.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
-
- Knows the dark side
- Posts: 4981
- Joined: 2015-12-09, 15:45
Re: Why Did Mozilla Remove XUL Add-ons?
The article also talks about how some extensions hooked into browser code and rewrote core functions on the fly. Why on earth would you try to support such things but for the fact that what documentation exists today is entirely the work of non Mozilla volunteers; the XUL reference and API is directly taken from XULPlanet, some pages haven't been updated since Gecko 1.x when 2.x was the one that introduced major changes. All these are excuses to cover up a totally sloppy development process and an unwillingness to divert some of their millions of dollars towards hiring competent technical writers to keep the documentation coherent and in step with the API changes instead of the half assed mess that it remains, from the beginning to this day (yes, I've cursorily browsed Web Extension documentation and surprise, even that remains incomplete).
Mozilla's biggest asset was the application platform itself, of which Firefox and Thunderbird are mere clients. They could have pushed it as a bridge between the desktop and web, as an alternate to other cross platform toolkits like Qt, given that you only need to use Javascript and XML (XUL) to create full fledged desktop class applications and widgets instead of having to learn/deal with C++. They could've built a runtime for Android so that one can create UI widgets for it using the same XUL (or a mobile specific subset). Partner with open source heavyweights like the Eclipse Foundation to create IDE plugins to make it easier for developers to adopt and use it. But no, the advent of Chrome lit the wrong kind of fire under their backside, the one that spells 'imitation is the sincerest form of flattery' and here we are today.
Mozilla's biggest asset was the application platform itself, of which Firefox and Thunderbird are mere clients. They could have pushed it as a bridge between the desktop and web, as an alternate to other cross platform toolkits like Qt, given that you only need to use Javascript and XML (XUL) to create full fledged desktop class applications and widgets instead of having to learn/deal with C++. They could've built a runtime for Android so that one can create UI widgets for it using the same XUL (or a mobile specific subset). Partner with open source heavyweights like the Eclipse Foundation to create IDE plugins to make it easier for developers to adopt and use it. But no, the advent of Chrome lit the wrong kind of fire under their backside, the one that spells 'imitation is the sincerest form of flattery' and here we are today.
"One hosts to look them up, one DNS to find them and in the darkness BIND them."
Linux Mint 21 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX
Linux Mint 21 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX
Re: Why Did Mozilla Remove XUL Add-ons?
So another words, mozilla was lazy and greedy and didn't want to spend or work on preserving a good idea. Smh...Mozilla's biggest asset was the application platform itself, of which Firefox and Thunderbird are mere clients. They could have pushed it as a bridge between the desktop and web, as an alternate to other cross platform toolkits like Qt, given that you only need to use Javascript and XML (XUL) to create full fledged desktop class applications and widgets instead of having to learn/deal with C++. They could've built a runtime for Android so that one can create UI widgets for it using the same XUL (or a mobile specific subset). Partner with open source heavyweights like the Eclipse Foundation to create IDE plugins to make it easier for developers to adopt and use it. But no, the advent of Chrome lit the wrong kind of fire under their backside, the one that spells 'imitation is the sincerest form of flattery' and here we are today.
-
- Add-ons Team
- Posts: 582
- Joined: 2017-01-14, 02:40
- Location: Philippines
Re: Why Did Mozilla Remove XUL Add-ons?
-
- Knows the dark side
- Posts: 4981
- Joined: 2015-12-09, 15:45
Re: Why Did Mozilla Remove XUL Add-ons?
Agree with the remote XUL. They just nixed support for it like it was something to be feared. And today we are stuck with goddamn Electron that has ruined desktop applications.
"One hosts to look them up, one DNS to find them and in the darkness BIND them."
Linux Mint 21 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX
Linux Mint 21 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX
Re: Why Did Mozilla Remove XUL Add-ons?
Ok, Challenge Time.
Compile a list of threads that talk about Fuel, Jetpack, WebEx, sandbox, remote xul, and uxl extensions of 2014 on.
Go.
Compile a list of threads that talk about Fuel, Jetpack, WebEx, sandbox, remote xul, and uxl extensions of 2014 on.
Go.
-
- Pale Moon guru
- Posts: 35637
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: Why Did Mozilla Remove XUL Add-ons?
Nope.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite