9 ms·

The topic's been discussed to death, but I'm really disappointed that Firefox extensions have gone the direction of Chrome's. Sure, it's nice to have compatibil

The topic's been discussed to death, but I'm really disappointed that Firefox extensions have gone the direction of Chrome's. Sure, it's nice to have compatibility, but at the cost of Firefox's more powerful extensions? No thank you.

jd3 11y ago
Yeah it's honestly pretty disgusting. Mozilla's strong add-on system has been one of their largest advertisable features for /years/. Just because a bunch of people have switched to inferior webkit/blink based browsers doesn't necessarily mean that the opposition's technology is superior. If I were the head of Mozilla, I'd get rid of everyone who has suggested: removing complete themes, removing the XUL/XPCOM add-ons and SDK, cutting off support for thunderbird/SeaMonkey/etc. Servo is an interesting browser project, but it's also a /separate/ project. They need to stop focusing on stupid fluff like pocket/hello/etc; instead, focus on bug zapping and core technology improvements (HTML5, etc.) If Mozilla continues gimping their core software any more, their user base will literally be 0. Disclaimer: I am an ardent supported of the Suite (SeaMonkey) and everything Mozilla will be doing in the next year will probably completely kill it (ChatZilla, themes, add-ons, etc.) Example: by this time next year, pretty much nothing you see here will be possible in SeaMonkey anymore thanks to the idiotic decisions from the Mozilla top brass: http://i.imgur.com/g4SwoFa.png http://i.imgur.com/g4SwoFa.png http://i.imgur.com/uDHcZpw.png http://i.imgur.com/uDHcZpw.png http://i.imgur.com/fO4Qz8A.png http://i.imgur.com/fO4Qz8A.png
- yuhong 11y ago
  I have been thinking that the move to Servo and browser.html is a good time to do things like restore customizable toolbars, since the UI would need to be rewritten anyway.
  - pcwalton 11y ago
    browser.html doesn't even have toolbars.
- nwah1 11y ago
  You have a misunderstanding of what is going on. Hello, for instance, is not some sort of project is draining resources and/or bloating firefox. It is essentially a WebRTC demonstration. Since WebRTC is a technology that needs to be implemented anyways, and is worth promoting, Hello becomes very interesting. It is basically just a little bit of javascript that runs on top of all the WebRTC code that they'd have to build anyways. Trying to do cross-platform screensharing, for instance, can be quite a hassle, but this will allow it to be done all without any sort of plugins, or any need for TeamViewer, GotoMeeting, etc. And as for XUL and XPCOM, they've already been moving away from it internally for years. It is horrible. Talk about bloat and security problems. And they already are needing to rewrite their APIs for things like Electrolysis, which I assume we want. So why not actually do a good job with the rewrite? The ultimate goal is to have the UI based on web standards (browser.html). This will reduce bloat and reduce the attack surface. And the UI will only get more customizable as a result.
  - nathancahill 11y ago
    > the UI will only get more customizable as a result. It's not the UI, it's the APIs behind powerful addons like Firebug that made Firefox the browser that it is. Those powerful APIs are going, going, gone.
    - clouddrover 11y ago
      Firebug 3 integrates with Firefox's native DevTools so you'll still have Firebug (or you can just use Firefox's DevTools without Firebug if you want): https://hacks.mozilla.org/2015/10/firebug-devtools-integration/ https://hacks.mozilla.org/2015/10/firebug-devtools-integrati...
      - nathancahill 11y ago
        Firebug isn't what's at stake here. It's the level of API access to browser internals that allowed things like Firebug to be built.
        11y ago
- aswan 11y ago
  It's remarkable the extent to which people assume the worst every time this topic comes up. The Mozilla stance has always been that the add-on community is a huge asset but that supporting add-ons based on XUL, XPCOM, and the SDK imposes real costs in security, performance, and maintainability. The plan, intended to keep the benefits while addressing the problems, is to migrate to a new set of APIs -- web extensions. This is meant to be a migration, not a narrowing of the capabilities -- building compatibility for existing Chrome extensions is just the first step in this plan, when that foundation is in place the next steps are to extend the webextensions APIs to keep expanding the set of add-ons that can be written as webextensions. A transition like this has two halves: adding the new (performant, maintainable, secure) APIs and deprecating the old ones. Comments like the one above jump to the bizarre conclusion that Mozilla will decide to remove of the old APIs but never add the new ones. The closest thing to an explanation for why this would happen is ... uh, something about pocket and hello?
  - kuschku 11y ago
    Mozilla has publicly said several times that they will NOT provide the same set of APIs. What we want is the ability to modify the whole browser chrome as if it was a website, and the ability to modify every action that happens in the browser. (For example, for tree style tabs, or a tab bar at the bottom, or stuff like redirecting some keypresses to other processes). Vivaldi does provide these things. Vivaldi allows users to literally rewrite 100% of the actual browser with simple JS addons. Mozilla should provide at least what Vivaldi provides.
  - protomyth 11y ago
    > XUL, XPCOM, and the SDK imposes real costs in security, performance, and maintainability. Is there some report on the security implications of supporting XUL?
  - the8472 11y ago
    In my eyes mozilla's stance on security is patronizing towards power-users because it assumes that every addon and every non-root application on the system is potentially hostile. Thus the goal is to prevent free interaction between processes or between addons and native in general (unix philosophy anyone?). Everyone has to suffer just to protect those who click on "yes, install" whenever prompted. The result are less powerful APIs in the name of security. Just look at addon signing. Mozilla refuses to add an off switch to that (and thus user control) because they fear that some other processes already running on the user's computer might inject unsigned addons. In my eyes this is a crazy kind of threat model that basically writes off the user's system security as a lost cause and tries to defend FF against that lost cause. It's elevating mozilla's needs over interoperability between applications. Imagine if awk refused to run unless the parent process is bash, signed by canonical, because they deemed some other shell's argument expansion as potentially confusing to the user or something like that. Crazy, right?
- pjmlp 11y ago
  > Yeah it's honestly pretty disgusting. Mozilla's strong add-on system has been one of their largest advertisable features for /years/. Just because a bunch of people have switched to inferior webkit/blink based browsers doesn't necessarily mean that the opposition's technology is superior. For me, even though I also do web development now and then, the web should have stayed as interactive hypermedia documents. What matters are network protocols. I always use native applications, when given the option. As such, I never cared for add-ons other than dictionaries. Blocking ads and nasty JavaScript sites? That is what the computer networking configuration is for.
  - the8472 11y ago
    > Blocking ads and nasty JavaScript sites? That is what the computer networking configuration is for. If everything is behind cloudflare IPs and piped through TLS that gets more difficult. And you'd have to defeat all the certificate-pinning/sts/etc. security just to filter some stuff. On the other hand the browser has more knowledge about each request, e.g. whether it's actually intended to be executed as javascript or loaded as an image etc.
    - pjmlp 11y ago
      Yeah, but the other hand you have Adblockers selling themselves out with exceptions for partner companies.
      - the8472 11y ago
        There are a dozen content- and ad-blockers. Only one or two do what you mention.
rpgmaker 11y ago
They also "updated" the search box, beside extensions the main reason why I still prefer it over Chrome. Firefox is slowly but surely becoming unbearable. It's a real tragedy that its market share has suffered as much as it has but Chrome users aren't coming back. If they keep this Chrome-ization their remaining users just won't see any reason to choose Firefox over Chrome and they will leave.
- nol13 11y ago
  Still, an extension for a popular message board that was being developed was about to get me to switch to Chrome, but turns out that with almost no modifications it works great in Firefox nightly too! If not for that there's no way anyone was going to bother to port it.
- giovannibajo1 11y ago
  Yeah I agree. Firefox is slowly becoming a Chrome clone. It took them a long while to migrate everything to follow the Chrome lead (release strategy, update strategy, multiprocess architecture, sandboxing, extension API, HTML UI, etc.) but I wonder what's the benefit of having two identical browsers. Yes the HTML engine is different but then so what, I don't think end users are ever going to switch because of HTML engines.
  - nathancahill 11y ago
    Privacy is a big reason I'm still using Firefox over Chrome.
  - derefr 11y ago
    Does there need to be a difference? Having two independent "rival" implementations of every feature is useful for the health of the web development ecosystem. The two apps could just be completely interchangeable from a user's perspective—a single site giving users one or the other for download at random—and that would still be true.
    - malka 11y ago
clouddrover 11y ago
> but at the cost of Firefox's more powerful extensions? What do you believe you'll be missing? Add-on authors say the new API will meet their needs. Giorgio Maone, the author of NoScript, says he's satisfied with the direction of the development of the new API: https://hackademix.net/2016/03/09/webrequest-where-were-where-were-going/ https://hackademix.net/2016/03/09/webrequest-where-were-wher... If you develop some add-on that needs features the new API doesn't currently provide then I'd say the best thing to do is to get involved with the development and get those features added.
- Veratyr 11y ago
  Does the new API support things like tree style tabs [0]? This is one of the things I've failed to see other browsers implement. [0] https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/ https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...
  - detaro 11y ago
    The second link in the article goes to the WebExtensions overview page, which mentions "Tree Style Tabs" by name as something that new APIs need to be build for. https://wiki.mozilla.org/WebExtensions https://wiki.mozilla.org/WebExtensions
  - clouddrover 11y ago
    If it doesn't yet, it will. Support for add-ons like Tree Style Tabs has been on their radar since development of the new API started: 1. https://billmccloskey.wordpress.com/2015/08/21/firefox-add-on-changes/ https://billmccloskey.wordpress.com/2015/08/21/firefox-add-o... 2. https://wiki.mozilla.org/WebExtensions#Additional_APIs https://wiki.mozilla.org/WebExtensions#Additional_APIs 3. https://wiki.mozilla.org/WebExtensions/RoadMap https://wiki.mozilla.org/WebExtensions/RoadMap
    - the8472 11y ago
      That just means that certain popular addons will get the support necessary to have their needs satisfied. Some niche ideas won't get support and thus die. That's the problem with a gated system where you can only do things approved by HQ.

jd3 11y ago

Yeah it's honestly pretty disgusting. Mozilla's strong add-on system has been one of their largest advertisable features for /years/. Just because a bunch of people have switched to inferior webkit/blink based browsers doesn't necessarily mean that the opposition's technology is superior. If I were the head of Mozilla, I'd get rid of everyone who has suggested: removing complete themes, removing the XUL/XPCOM add-ons and SDK, cutting off support for thunderbird/SeaMonkey/etc. Servo is an interesting browser project, but it's also a /separate/ project. They need to stop focusing on stupid fluff like pocket/hello/etc; instead, focus on bug zapping and core technology improvements (HTML5, etc.) If Mozilla continues gimping their core software any more, their user base will literally be 0. Disclaimer: I am an ardent supported of the Suite (SeaMonkey) and everything Mozilla will be doing in the next year will probably completely kill it (ChatZilla, themes, add-ons, etc.) Example: by this time next year, pretty much nothing you see here will be possible in SeaMonkey anymore thanks to the idiotic decisions from the Mozilla top brass: http://i.imgur.com/g4SwoFa.png http://i.imgur.com/g4SwoFa.png http://i.imgur.com/uDHcZpw.png http://i.imgur.com/uDHcZpw.png http://i.imgur.com/fO4Qz8A.png http://i.imgur.com/fO4Qz8A.png

yuhong 11y ago
I have been thinking that the move to Servo and browser.html is a good time to do things like restore customizable toolbars, since the UI would need to be rewritten anyway.
- pcwalton 11y ago
  browser.html doesn't even have toolbars.
nwah1 11y ago
You have a misunderstanding of what is going on. Hello, for instance, is not some sort of project is draining resources and/or bloating firefox. It is essentially a WebRTC demonstration. Since WebRTC is a technology that needs to be implemented anyways, and is worth promoting, Hello becomes very interesting. It is basically just a little bit of javascript that runs on top of all the WebRTC code that they'd have to build anyways. Trying to do cross-platform screensharing, for instance, can be quite a hassle, but this will allow it to be done all without any sort of plugins, or any need for TeamViewer, GotoMeeting, etc. And as for XUL and XPCOM, they've already been moving away from it internally for years. It is horrible. Talk about bloat and security problems. And they already are needing to rewrite their APIs for things like Electrolysis, which I assume we want. So why not actually do a good job with the rewrite? The ultimate goal is to have the UI based on web standards (browser.html). This will reduce bloat and reduce the attack surface. And the UI will only get more customizable as a result.
- nathancahill 11y ago
  > the UI will only get more customizable as a result. It's not the UI, it's the APIs behind powerful addons like Firebug that made Firefox the browser that it is. Those powerful APIs are going, going, gone.
  - clouddrover 11y ago
    Firebug 3 integrates with Firefox's native DevTools so you'll still have Firebug (or you can just use Firefox's DevTools without Firebug if you want): https://hacks.mozilla.org/2015/10/firebug-devtools-integration/ https://hacks.mozilla.org/2015/10/firebug-devtools-integrati...
    - nathancahill 11y ago
      Firebug isn't what's at stake here. It's the level of API access to browser internals that allowed things like Firebug to be built.
      - 11y ago
aswan 11y ago
It's remarkable the extent to which people assume the worst every time this topic comes up. The Mozilla stance has always been that the add-on community is a huge asset but that supporting add-ons based on XUL, XPCOM, and the SDK imposes real costs in security, performance, and maintainability. The plan, intended to keep the benefits while addressing the problems, is to migrate to a new set of APIs -- web extensions. This is meant to be a migration, not a narrowing of the capabilities -- building compatibility for existing Chrome extensions is just the first step in this plan, when that foundation is in place the next steps are to extend the webextensions APIs to keep expanding the set of add-ons that can be written as webextensions. A transition like this has two halves: adding the new (performant, maintainable, secure) APIs and deprecating the old ones. Comments like the one above jump to the bizarre conclusion that Mozilla will decide to remove of the old APIs but never add the new ones. The closest thing to an explanation for why this would happen is ... uh, something about pocket and hello?
- kuschku 11y ago
  Mozilla has publicly said several times that they will NOT provide the same set of APIs. What we want is the ability to modify the whole browser chrome as if it was a website, and the ability to modify every action that happens in the browser. (For example, for tree style tabs, or a tab bar at the bottom, or stuff like redirecting some keypresses to other processes). Vivaldi does provide these things. Vivaldi allows users to literally rewrite 100% of the actual browser with simple JS addons. Mozilla should provide at least what Vivaldi provides.
- protomyth 11y ago
  > XUL, XPCOM, and the SDK imposes real costs in security, performance, and maintainability. Is there some report on the security implications of supporting XUL?
- the8472 11y ago
  In my eyes mozilla's stance on security is patronizing towards power-users because it assumes that every addon and every non-root application on the system is potentially hostile. Thus the goal is to prevent free interaction between processes or between addons and native in general (unix philosophy anyone?). Everyone has to suffer just to protect those who click on "yes, install" whenever prompted. The result are less powerful APIs in the name of security. Just look at addon signing. Mozilla refuses to add an off switch to that (and thus user control) because they fear that some other processes already running on the user's computer might inject unsigned addons. In my eyes this is a crazy kind of threat model that basically writes off the user's system security as a lost cause and tries to defend FF against that lost cause. It's elevating mozilla's needs over interoperability between applications. Imagine if awk refused to run unless the parent process is bash, signed by canonical, because they deemed some other shell's argument expansion as potentially confusing to the user or something like that. Crazy, right?
pjmlp 11y ago
> Yeah it's honestly pretty disgusting. Mozilla's strong add-on system has been one of their largest advertisable features for /years/. Just because a bunch of people have switched to inferior webkit/blink based browsers doesn't necessarily mean that the opposition's technology is superior. For me, even though I also do web development now and then, the web should have stayed as interactive hypermedia documents. What matters are network protocols. I always use native applications, when given the option. As such, I never cared for add-ons other than dictionaries. Blocking ads and nasty JavaScript sites? That is what the computer networking configuration is for.
- the8472 11y ago
  > Blocking ads and nasty JavaScript sites? That is what the computer networking configuration is for. If everything is behind cloudflare IPs and piped through TLS that gets more difficult. And you'd have to defeat all the certificate-pinning/sts/etc. security just to filter some stuff. On the other hand the browser has more knowledge about each request, e.g. whether it's actually intended to be executed as javascript or loaded as an image etc.
  - pjmlp 11y ago
    Yeah, but the other hand you have Adblockers selling themselves out with exceptions for partner companies.
    - the8472 11y ago
      There are a dozen content- and ad-blockers. Only one or two do what you mention.

rpgmaker 11y ago

They also "updated" the search box, beside extensions the main reason why I still prefer it over Chrome. Firefox is slowly but surely becoming unbearable. It's a real tragedy that its market share has suffered as much as it has but Chrome users aren't coming back. If they keep this Chrome-ization their remaining users just won't see any reason to choose Firefox over Chrome and they will leave.

nol13 11y ago
Still, an extension for a popular message board that was being developed was about to get me to switch to Chrome, but turns out that with almost no modifications it works great in Firefox nightly too! If not for that there's no way anyone was going to bother to port it.
giovannibajo1 11y ago
Yeah I agree. Firefox is slowly becoming a Chrome clone. It took them a long while to migrate everything to follow the Chrome lead (release strategy, update strategy, multiprocess architecture, sandboxing, extension API, HTML UI, etc.) but I wonder what's the benefit of having two identical browsers. Yes the HTML engine is different but then so what, I don't think end users are ever going to switch because of HTML engines.
- nathancahill 11y ago
  Privacy is a big reason I'm still using Firefox over Chrome.
- derefr 11y ago
  Does there need to be a difference? Having two independent "rival" implementations of every feature is useful for the health of the web development ecosystem. The two apps could just be completely interchangeable from a user's perspective—a single site giving users one or the other for download at random—and that would still be true.
  - malka 11y ago

clouddrover 11y ago

> but at the cost of Firefox's more powerful extensions? What do you believe you'll be missing? Add-on authors say the new API will meet their needs. Giorgio Maone, the author of NoScript, says he's satisfied with the direction of the development of the new API: https://hackademix.net/2016/03/09/webrequest-where-were-where-were-going/ https://hackademix.net/2016/03/09/webrequest-where-were-wher... If you develop some add-on that needs features the new API doesn't currently provide then I'd say the best thing to do is to get involved with the development and get those features added.

Veratyr 11y ago
Does the new API support things like tree style tabs [0]? This is one of the things I've failed to see other browsers implement. [0] https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/ https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...
- detaro 11y ago
  The second link in the article goes to the WebExtensions overview page, which mentions "Tree Style Tabs" by name as something that new APIs need to be build for. https://wiki.mozilla.org/WebExtensions https://wiki.mozilla.org/WebExtensions
- clouddrover 11y ago
  If it doesn't yet, it will. Support for add-ons like Tree Style Tabs has been on their radar since development of the new API started: 1. https://billmccloskey.wordpress.com/2015/08/21/firefox-add-on-changes/ https://billmccloskey.wordpress.com/2015/08/21/firefox-add-o... 2. https://wiki.mozilla.org/WebExtensions#Additional_APIs https://wiki.mozilla.org/WebExtensions#Additional_APIs 3. https://wiki.mozilla.org/WebExtensions/RoadMap https://wiki.mozilla.org/WebExtensions/RoadMap
  - the8472 11y ago
    That just means that certain popular addons will get the support necessary to have their needs satisfied. Some niche ideas won't get support and thus die. That's the problem with a gated system where you can only do things approved by HQ.