4 ms·

Users remember Firefox as the browser that gives them control over their experience Power users, or users? Among the crowd here, sure. But in the rest of the w

Users remember Firefox as the browser that gives them control over their experience Power users, or users? Among the crowd here, sure. But in the rest of the world? unlike Chrome which babysits and won't let you interfere with Google's need to harvest data. Firefox has been getting more and more nannyish and chromelike with every release. * There's the "let's throw out semantic versioning since Chrome already did it" * There's the UI rework which sacrificed information density and usability for what I evaluate as a weak attempt to look more like Chrome. * There's the "thou shalt not install plugins from places other than we say is okay" rule that was recently implemented - which Chrome did first. * There's the upcoming "all your plugins are going to break, many permanently" when XUL gets thrown out and the new hotness won't have feature parity at release (in other words, Firefox plugins will be as limited as Chrome plugins)

Dylan16807 11y ago
Version numbers and menu placement have nothing to do with being "nannyish" or data collection. Can you name three good plugins? Removing an insecure legacy tech is not a big problem when the extension API is right there.
- Karunamon 11y ago
  I said more nannyish AND chromelike. Three good plugins? Have nine. Here's my plugin load right now: * uBlock * Privacy Badger * HTTPS Everywhere * Calomel SSL Validation * FoxReplace * Vimperator (which used to be Pentadactyl before Mozilla decided that I can't use it anymore[1]) * Noscript * DevEdition theme enabler * 1Password And please spare me the "insecure legacy tech" argument. The new plugin architecture explicitly can't do things that the existing plugins can, per Mozilla's own words[2]. And also per Mozilla's own words, the new architecture takes after Chrome. if I wanted to use Chrome and have its limitations, I'd fucking use Chrome. And I have zero faith that they will fix those limitations by launch time either. seeing as how their attitude towards adding features nobody wants (Pocket, Hello, Australis) or removing features people actually want (installing whatever plugins I damn well please without a nann^H^H^H^H approval process, accessing sites with broken certs) up until now has been to ignore all feedback and just do it anyways. [1]: https://pbs.twimg.com/media/CZVvYtKUsAAtMl7.png:large https://pbs.twimg.com/media/CZVvYtKUsAAtMl7.png:large [2]: https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...
  - pcwalton 11y ago
    XUL is insecure legacy tech. There isn't a coherent argument otherwise: XUL is insecure in that it gives addons all the power of the browser, and XUL is legacy, unspecified, single-implementation-wedded XML stuff from the '90s whose functionality has been entirely superseded by HTML at this point. The idea that nothing can be insecure and legacy unless the new alternatives support absolutely everything the old technology did is absurd: that would prevent us from calling DOS "obsolete and legacy" because apps running in ring 0 can do things that apps running in ring 3 can't. XUL may well be insecure legacy tech that performs a useful task for you, and that's why care is being taken to make sure the important extensions continue to work in the new Web Extensions world.
    - somebehemoth 11y ago
      > ...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
> * There's the upcoming "all your plugins are going to break, many permanently" when XUL gets thrown out and the new hotness won't have feature parity at release (in other words, Firefox plugins will be as limited as Chrome plugins) As a long time firefox user this is the one that hurts the most. I honestly hope someone forks firefox to preserve this functionality. I know it is a losing proposition in the long run, but right now my only option is to not upgrade firefox (which isn't an option for very long). I post this here to vent and with the hopes that there already exists a project to preserve XUL functionality and I am simply unaware. P.S. I use tab groups, a native feature, and have been dreading this ominous warning that appears whenever I open them: "Heads up! Tab Groups will be removed from Firefox soon." I can't even disable the warning.
- dblohm7 11y ago
  You can change the API without removing functionality. WebExtensions are going to be based upon the Chrome extension API, but will be expanding on that so that many of the "uniquely Firefox" addons can still exist.
- richardboegli 11y ago
  Palemoon I've been a happy user of it more many years. Once you use it, you'll wish you'd found it sooner ;)
jcranmer 11y ago
> There's the "let's throw out semantic versioning since Chrome already did it" Firefox never followed semantic versioning. Versions 2.0, 3.0, 3.5, 3.6, and 4.0 all had equally major changes to them. It's worse if you look at the internal version numbers: 1.8, 1.9, 1.9.1, 1.9.2, 4.0. The change to the rapid-release model was driven more by the pain of the protracted Firefox 4 release than by trying to ape Chrome. > There's the UI rework which sacrificed information density and usability for what I evaluate as a weak attempt to look more like Chrome. Actually, Firefox started developing the design before Chrome did. They just took far, far, far longer.
- Karunamon 11y ago
  Fair enough on the versioning thing - but as far as the UI, Chrome's main interface has remained almost identical to its initial release seven years ago. Firefox was really working on something similar for that long?
- JonathonW 11y ago
  As far as I can tell, the Australis work dates back roughly to 2012 (that's when their wiki meeting notes start, and when the Australis tracking bug in Bugzilla was opened). You may be mixing Australis up with the theme work done for Firefox 4.0 (which moved tabs to the top by default and added the orange Firefox menu button). The early work on that would've been contemporaneous with the earliest public versions of Chrome (2/3/4)-- the design that would become Firefox 4 started being shown off in public around the fall of 2009.

Dylan16807 11y ago

Version numbers and menu placement have nothing to do with being "nannyish" or data collection. Can you name three good plugins? Removing an insecure legacy tech is not a big problem when the extension API is right there.

Karunamon 11y ago
I said more nannyish AND chromelike. Three good plugins? Have nine. Here's my plugin load right now: * uBlock * Privacy Badger * HTTPS Everywhere * Calomel SSL Validation * FoxReplace * Vimperator (which used to be Pentadactyl before Mozilla decided that I can't use it anymore[1]) * Noscript * DevEdition theme enabler * 1Password And please spare me the "insecure legacy tech" argument. The new plugin architecture explicitly can't do things that the existing plugins can, per Mozilla's own words[2]. And also per Mozilla's own words, the new architecture takes after Chrome. if I wanted to use Chrome and have its limitations, I'd fucking use Chrome. And I have zero faith that they will fix those limitations by launch time either. seeing as how their attitude towards adding features nobody wants (Pocket, Hello, Australis) or removing features people actually want (installing whatever plugins I damn well please without a nann^H^H^H^H approval process, accessing sites with broken certs) up until now has been to ignore all feedback and just do it anyways. [1]: https://pbs.twimg.com/media/CZVvYtKUsAAtMl7.png:large https://pbs.twimg.com/media/CZVvYtKUsAAtMl7.png:large [2]: https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...
- pcwalton 11y ago
  XUL is insecure legacy tech. There isn't a coherent argument otherwise: XUL is insecure in that it gives addons all the power of the browser, and XUL is legacy, unspecified, single-implementation-wedded XML stuff from the '90s whose functionality has been entirely superseded by HTML at this point. The idea that nothing can be insecure and legacy unless the new alternatives support absolutely everything the old technology did is absurd: that would prevent us from calling DOS "obsolete and legacy" because apps running in ring 0 can do things that apps running in ring 3 can't. XUL may well be insecure legacy tech that performs a useful task for you, and that's why care is being taken to make sure the important extensions continue to work in the new Web Extensions world.
  - somebehemoth 11y ago
    > ...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

> * There's the upcoming "all your plugins are going to break, many permanently" when XUL gets thrown out and the new hotness won't have feature parity at release (in other words, Firefox plugins will be as limited as Chrome plugins) As a long time firefox user this is the one that hurts the most. I honestly hope someone forks firefox to preserve this functionality. I know it is a losing proposition in the long run, but right now my only option is to not upgrade firefox (which isn't an option for very long). I post this here to vent and with the hopes that there already exists a project to preserve XUL functionality and I am simply unaware. P.S. I use tab groups, a native feature, and have been dreading this ominous warning that appears whenever I open them: "Heads up! Tab Groups will be removed from Firefox soon." I can't even disable the warning.

dblohm7 11y ago
You can change the API without removing functionality. WebExtensions are going to be based upon the Chrome extension API, but will be expanding on that so that many of the "uniquely Firefox" addons can still exist.
richardboegli 11y ago
Palemoon I've been a happy user of it more many years. Once you use it, you'll wish you'd found it sooner ;)

jcranmer 11y ago

> There's the "let's throw out semantic versioning since Chrome already did it" Firefox never followed semantic versioning. Versions 2.0, 3.0, 3.5, 3.6, and 4.0 all had equally major changes to them. It's worse if you look at the internal version numbers: 1.8, 1.9, 1.9.1, 1.9.2, 4.0. The change to the rapid-release model was driven more by the pain of the protracted Firefox 4 release than by trying to ape Chrome. > There's the UI rework which sacrificed information density and usability for what I evaluate as a weak attempt to look more like Chrome. Actually, Firefox started developing the design before Chrome did. They just took far, far, far longer.

Karunamon 11y ago
Fair enough on the versioning thing - but as far as the UI, Chrome's main interface has remained almost identical to its initial release seven years ago. Firefox was really working on something similar for that long?
JonathonW 11y ago
As far as I can tell, the Australis work dates back roughly to 2012 (that's when their wiki meeting notes start, and when the Australis tracking bug in Bugzilla was opened). You may be mixing Australis up with the theme work done for Firefox 4.0 (which moved tabs to the top by default and added the orange Firefox menu button). The early work on that would've been contemporaneous with the earliest public versions of Chrome (2/3/4)-- the design that would become Firefox 4 started being shown off in public around the fall of 2009.