3 ms·

> ...whose functionality has been entirely superseded by HTML at this point... This is just not true. Not all functionality enabled by XUL can be executed wi

> ...whose functionality has been entirely superseded by HTML at this point... This is just not true. Not all functionality enabled by XUL can be executed with Web Extensions. Perhaps this will be so in the future. > ...and that's why care is being taken to make sure the important extensions continue to work... Who decides what extensions are "important" and therefore worthy of working in this new "web extensions world"? I guess my point is that if there were true parity between web extensions and XUL there would be no need for concern. However, that is not the case and we know many extensions cannot be recreated. Therein lies the problem. Many users will be negatively affected by this change and I am still trying to understand the benefit. For example, why are Web Extensions mutually exclusive to XUL extensions? I get that supporting both is inelegant, but it at least reflects the current reality of Firefox usage.

pcwalton 11y ago
> This is just not true. Not all functionality enabled by XUL can be executed with Web Extensions. Perhaps this will be so in the future. We should be careful to separate XUL-the-layout-system from XPCOM (really, Firefox's XPCOM components). The layout features of HTML and standard CSS have entirely superseded the layout features of XUL in the ways that matter. (There are some exceptions—the tree view control is often cited—but there are lots of HTML substitutes for these things, and XUL has so many problems that on balance the downsides outweigh the upsides at this point.) What you're actually referring to is the XPCOM components provided by Firefox. It is true that Web Extensions, as of this moment, do not replicate all of that functionality. However, as I said before, that isn't a valid argument that XUL should be kept around forever any more than the fact that 16-bit DOS apps have direct control over the hardware is a valid argument that DOS support should be kept around forever. > For example, why are Web Extensions mutually exclusive to XUL extensions? Well, they aren't. But the reason for Web Extensions is to deprecate XUL extensions, and the reason for deprecating XUL extensions is that XUL is legacy, insecure tech.
- somebehemoth 11y ago
  Thank you for explaining the difference between XPCOM and XUL layouts > that isn't a valid argument that XUL should be kept around forever any more than the fact that 16-bit DOS apps have direct control over the hardware is a valid argument that DOS support should be kept around forever I don't think I argued that it should be kept around forever. The point I was refuting was that Web Extensions are ready to replace existing firefox extensions. At some point it will be true that Web Extensions are as capable as existing firefox extensions. At that point deprecating existing extensions make sense (or slightly sooner). Lots of people rely on existing extensions. Taking those extensions away without a real alternative solution is just rude to end users. This move may be past due from a security standpoint, but it is extremely premature from a user experience perspective.

pcwalton 11y ago

> This is just not true. Not all functionality enabled by XUL can be executed with Web Extensions. Perhaps this will be so in the future. We should be careful to separate XUL-the-layout-system from XPCOM (really, Firefox's XPCOM components). The layout features of HTML and standard CSS have entirely superseded the layout features of XUL in the ways that matter. (There are some exceptions—the tree view control is often cited—but there are lots of HTML substitutes for these things, and XUL has so many problems that on balance the downsides outweigh the upsides at this point.) What you're actually referring to is the XPCOM components provided by Firefox. It is true that Web Extensions, as of this moment, do not replicate all of that functionality. However, as I said before, that isn't a valid argument that XUL should be kept around forever any more than the fact that 16-bit DOS apps have direct control over the hardware is a valid argument that DOS support should be kept around forever. > For example, why are Web Extensions mutually exclusive to XUL extensions? Well, they aren't. But the reason for Web Extensions is to deprecate XUL extensions, and the reason for deprecating XUL extensions is that XUL is legacy, insecure tech.

somebehemoth 11y ago
Thank you for explaining the difference between XPCOM and XUL layouts > that isn't a valid argument that XUL should be kept around forever any more than the fact that 16-bit DOS apps have direct control over the hardware is a valid argument that DOS support should be kept around forever I don't think I argued that it should be kept around forever. The point I was refuting was that Web Extensions are ready to replace existing firefox extensions. At some point it will be true that Web Extensions are as capable as existing firefox extensions. At that point deprecating existing extensions make sense (or slightly sooner). Lots of people rely on existing extensions. Taking those extensions away without a real alternative solution is just rude to end users. This move may be past due from a security standpoint, but it is extremely premature from a user experience perspective.