4 ms·

Care to elaborate? I still mourn the death of XUL. The extensions that really meant something are now gone or available in versions that are much worse than the

Care to elaborate? I still mourn the death of XUL. The extensions that really meant something are now gone or available in versions that are much worse than their predecessors.

danudey 7y ago
Here's a random writeup I found after some googling. I'm pretty sure that I've recently read a better description of how and why they removed XUL, but I can't find any specific overviews that seem better than this one: https://github.com/mozilla/firefox-browser-architecture/blob/0b353dfe69765d8357079f6f4f9425e4c03e4b7f/text/0003-problems-with-xul.md https://github.com/mozilla/firefox-browser-architecture/blob... The short version is that XUL is a mozilla-specific implementation of functionality that can be accomplished with standard html5/CSS/etc., and thus using specifically XUL to handle the UI is inefficient from a developer standpoint, which can also introduce bugs, etc. as developers are forced to work on/use a technology with which they're not familiar. XUL is being replaced with (was replaced with?) the standard HTML5 engine, which is continually being improved, updated, secured, optimized, etc. IIRC, there's no reason that an extension couldn't do what it did in XUL, so the likelihood is that the lack of those extensions isn't directly related to Mozilla removing XUL, but rather extension developers re-implementing their extensions in HTML5 for Chrome, which is a vastly more common platform for browser extensions in my experience, instead of re-implementing their extensions in HTML5 for Firefox.
- yjftsjthsd-h 7y ago
  > there's no reason that an extension couldn't do what it did in XUL The XUL-webextension transition resulted in a huge loss of API surface. This cost us vim keybindings, tree style tabs, the ability to modify the new tab page, and probably some other things that I'm forgetting. While they eventually added some replacements, it's still not 100% back to where it was (ex. tree style tabs now works, but can't hide the original tab bar).
- WorldMaker 7y ago
  > IIRC, there's no reason that an extension couldn't do what it did in XUL XUL extensions were given full access to the XUL DOM for the entire browser, whereas WebExtensions are limited in their sandbox to known extension points rather than having full HTML DOM access to the entire browser. Also, while WebExtensions still have access to messaging channels to websites/native code/outside applications, it is indirect (and permissions/sandbox mediated). XUL extensions' XPCOM (like Microsoft's COM) gave a much direct path both in to the HTML DOM of individual websites and outward for native platform code to be written in languages like C/C++. (All of the above of which include additional reasons why XUL/XPCOM may be security liabilities if your goal is a secure browser: free reign of the browser DOM, website DOM, and easier access to native code.)

Care to elaborate? I still mourn the death of XUL. The extensions that really meant something are now gone or available in versions that are much worse than their predecessors.

danudey 7y ago

Here's a random writeup I found after some googling. I'm pretty sure that I've recently read a better description of how and why they removed XUL, but I can't find any specific overviews that seem better than this one: https://github.com/mozilla/firefox-browser-architecture/blob/0b353dfe69765d8357079f6f4f9425e4c03e4b7f/text/0003-problems-with-xul.md https://github.com/mozilla/firefox-browser-architecture/blob... The short version is that XUL is a mozilla-specific implementation of functionality that can be accomplished with standard html5/CSS/etc., and thus using specifically XUL to handle the UI is inefficient from a developer standpoint, which can also introduce bugs, etc. as developers are forced to work on/use a technology with which they're not familiar. XUL is being replaced with (was replaced with?) the standard HTML5 engine, which is continually being improved, updated, secured, optimized, etc. IIRC, there's no reason that an extension couldn't do what it did in XUL, so the likelihood is that the lack of those extensions isn't directly related to Mozilla removing XUL, but rather extension developers re-implementing their extensions in HTML5 for Chrome, which is a vastly more common platform for browser extensions in my experience, instead of re-implementing their extensions in HTML5 for Firefox.

yjftsjthsd-h 7y ago
> there's no reason that an extension couldn't do what it did in XUL The XUL-webextension transition resulted in a huge loss of API surface. This cost us vim keybindings, tree style tabs, the ability to modify the new tab page, and probably some other things that I'm forgetting. While they eventually added some replacements, it's still not 100% back to where it was (ex. tree style tabs now works, but can't hide the original tab bar).
WorldMaker 7y ago
> IIRC, there's no reason that an extension couldn't do what it did in XUL XUL extensions were given full access to the XUL DOM for the entire browser, whereas WebExtensions are limited in their sandbox to known extension points rather than having full HTML DOM access to the entire browser. Also, while WebExtensions still have access to messaging channels to websites/native code/outside applications, it is indirect (and permissions/sandbox mediated). XUL extensions' XPCOM (like Microsoft's COM) gave a much direct path both in to the HTML DOM of individual websites and outward for native platform code to be written in languages like C/C++. (All of the above of which include additional reasons why XUL/XPCOM may be security liabilities if your goal is a secure browser: free reign of the browser DOM, website DOM, and easier access to native code.)