Originally posted by Delgarde
View Post
Announcement
Collapse
No announcement yet.
Mozilla To Make Add-Ons Use WebExtensions API, Compatible With Chrome
Collapse
X
-
-
Originally posted by Luke View PostThe 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.
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
-
Originally posted by johnp117 View Postedit: 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.
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
-
Originally posted by johnp117 View PostAnd 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.
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
Comment