Announcement

Collapse
No announcement yet.

Mozilla To Make Add-Ons Use WebExtensions API, Compatible With Chrome

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Delgarde View Post

    ...Their problem is basically that the Firefox internals are showing their age, and that they need to make big changes to remain viable ...
    How do you solve that problem? You can't keep up without changing things, but you can't change things without a lot of unwelcome breakage in the process...
    Exactly. They've done the best that they could do in a difficult situation. Yes, there is going to be the usual clamoring to fork, threats to stop development, etc. etc. etc. but the vast majority of people will actually appreciate the increased availability of extensions - and most developers will appreciate the fact that their extensions will run on Firefox, Chrome and Opera. As the old saying goes... the train is coming, either get on board, or get out of the way.

    Comment


    • #22
      Originally posted by Luke View Post
      The changes to extensions mean users will have to pin their browser versions until all extensions they depend on catch up. In some cases it might be necessary to pull the Firefox source code and remove the signature check in order to run an unsigned extension. I require not only NoScript and Disconnect but also CanvasBlocker, which is NOT signed. I won't run any browser that I cannot protect from being tracked, that's why I purged Chromium years ago.
      Actually CanvasBlocker is signed. Just not the newest version... Review queue issues (which is also a reason for the Webextensions API: to shorten review time)
      NoScript's developer Giorgio Maone is already in contact with Mozilla to help design the Webextensions API with features he needs to have. All developers are free to do so, and especially the Top-Add-On Authors are encouraged. That's why they're announcing the plan so early.
      Disconnect is not really necessary anymore, because its blocklist is built into firefox, just hidden behind the privacy.trackingprotection.enabled and privacy.trackingprotection.ui.enabled preferences, and for the moment only defaults to active in private browsing mode IIRC.

      Mozilla is doing the best they can to keep up with new developments in the browser-world (Chrome multiprocess vs e10s, WebKit/Edge vs Servo), but that's not possible without breaking parts of the ecosystem, because simply Firefox is and will be the (for add-on authors) most permissive browser. If you have a million ways for Add-Ons to interact with your browser you can't just NOT break parts of them if you replace or rewrite major parts of the browser.
      (They tried to create an API (Jetpack/Addon-SDK) to easen this process long ago, but adoption of it isn't as good as it was hoped, so developing an API that actually has (downwards-)compatibility to other browsers will hopefully create a better adoption rate (also, during Jetpack-development, Servo was IIRC in it's very early stages and the former couldn't technically provide Servo-Add-On-APIs at that moment))

      And because Firefox is free (as in speech, besides the name) and free (as in beer), there are already forks (like Palemoon) that will most likely continue to provide a version of Firefox with those deprecated components, preserving compatibility for those power-users who don't want to have Servo and alike.

      edit: Also it will never be necessary to manually patch out the signed extension requirement, because Mozilla provides unbranded and development builds with the xpinstall.signatures.required preference.
      This post is related to "The Future of Developing Firefox Add-ons" on the add-ons blog. Please read that first for context. A couple of concerns from that post have come up that I would like to address here. One concern people have is that their favorite add-on is no longer going to be supported, especially?
      Last edited by johnp117; 23 August 2015, 07:50 AM.

      Comment


      • #23
        Originally posted by johnp117 View Post
        edit: Also it will never be necessary to manually patch out the signed extension requirement, because Mozilla provides unbranded and development builds with the xpinstall.signatures.required preference.
        To clarify, the "and development builds" are Firefox Developer Edition (formerly Aurora channel). They've got the Firefox branding intact and, in my experience, Aurora channel is stable enough to be indistinguishable from Stable channel. (Mozilla has done a marvellous job of piling on enough unit testing and Nightly-channel testing to keep Aurora stable.)

        I's trivial to change it back to its old Aurora channel look and behaviour. Just toggle "Allow Firefox Developer Edition and Firefox to run at the same time" under Preferences to get your existing Stable-channel profile back and choose the "Default" theme rather than the "Developer Edition" theme to get it to match your desktop theming settings.
        Last edited by ssokolow; 24 August 2015, 12:59 AM.

        Comment


        • #24
          Originally posted by johnp117 View Post
          And because Firefox is free (as in speech, besides the name) and free (as in beer), there are already forks (like Palemoon) that will most likely continue to provide a version of Firefox with those deprecated components, preserving compatibility for those power-users who don't want to have Servo and alike.
          Not for long, I suspect. Right now, those forks typically have only minor divergence - they're more than just customised Firefox builds, but they're kept in sync with upstream Mozilla, and since they're all small projects, they're totally reliant on upstream Mozilla to maintain the core code.

          But in the situation described, that changes - Mozilla will be making massive changes to the Firefox core code, ripping out XUL/XPCOM, breaking extensions all over the place, and basically changing how everything works. And if those projects like Palemoon don't want to go along with that, then someone needs to step up and maintain a complete fork... to manage their own security fixes, etc. All the problems which a large project like Mozilla is currently struggling to overcome, they become the problems of the much smaller projects that try to fork from it.

          It's very similar to the situation with MATE, I think. They didn't like decisions made by upstream and chose to fork - which left them with full responsibility for maintaining a codebase which upstream had chosen to throw away as being too difficult to maintain. And to be honest, MATE have lasted longer than I thought they would - taking ownership of a crappy old codebase, and slowly making progress on modernising it - but they remain chronically under-resourced for what they're trying to do. And I think projects like Palemoon will would have the same problem if they chose to completely fork from upstream Firefox development - they're just not big enough to succeed at it.

          Comment

          Working...
          X