"BTW, if you really want to show us that you trust this much in these new WebExtensions, the first ones to appear at AMO should be Pocket and Hello.
Remove that code from the core Firefox and put it where it always should have been: an extension that anyone interested can easily install."
And a more serious comment from a developer of DownThemAll!:
"I was thinking of abandoning add-on development for a while now, mostly because of the Walled Garden signing approach that went live, which I strongly objected to and still strongly object to… I might have come to terms with it, once I see it play out in an actual implemention…
But “deprecating” XUL-based add-ons with XPCOM access takes the cake. Once that happens, I will abandon ship for sure. Simply because I cannot continue developing most add-ons at all as they will not and cannot fit into any “WebExtensions” API. The flexibility of what XUL-based add-ons can do IS the major selling point of the Firefox add-ons ecosystem and therefore IS one of the last remaining selling points of Firefox itself that isn’t purely ideological. In comparison, the APIs that Chrome and competitors offer, that the Firefox Jetpack/ Add-on SDK offers, are just… toys.
To give a little background about myself to show that I’m not just the random hater shooting a drive-by comment: I wrote some more or less successful add-ons in the past, including DownThemAll!, and reviewed many, many add-ons as an AMO volunteer."
I use Tab Mix Plus for multi-row tabs in Firefox. It's so important to how I browse that it's the main reason why I use Firefox. If it goes away, then I have no reason to use Firefox.
I think that may be overly pessimistic: The post says they are working to extend WebExtensions in ways to allow addons that currently can't work in the Chrome etc. addon APIs.
I'm not sure if that will address that concern, it depends how far they will go with that, but at least it is clear that doing much better than basic WebExtensions/Jetpack/etc. is intended.
With regard to making the integrated Pocket and Hello features into addons, I think they absolutely should. And I wouldn't even mind if those addons came pre-installed, such that the out-of-the-box experience for the average user is identical, but advanced users can disable or uninstall these addons if they don't want or need them.
> The Beta and Release versions of Firefox based on 42 and above (Beta 42 will be released at the same time as Firefox 41) will remove the preference that allows unsigned extensions to be installed, and will disable and/or prevent the installation of unsigned extensions.
This is very bad news for me. I'm a power user that prefers the balance of new features/chance of breakage that the Beta channel offers and I take full responsibility for the addons I install and the security decisions I make. I don't need Mozilla to be "defending" me in this case.
«The Nightly and Developer Editions of Firefox based on 42 and above will retain the preference to disable signing enforcement, allowing the development and/or use of unsigned add-ons in those versions»
So I think running the Developer Edition (which I expect to be much more stable than Nightly) is probably your best bet.
One reason for add-on signing is that there's a major attack on Firefox using stolen add-on IDs to insert malware. This started in early 2015, and one of my add-ons has about one-third bogus versions out there. They all have different random version numbers, typically above 1000. Those are about to get flushed out of the ecosystem.
Whether add-on signing is part of a power trip at Mozilla to enforce a walled garden with Mozilla-favorable policies remains to be seen. When Mozilla blocks an add-on which disables Pocket or Sync or Hello, we'll know that AMO has turned to the dark side.
Fully agree. On Mac OS X you can still run unsigned apps, but you have to be savvy enough to do so. Mozilla should at the very least adopt such an approach.
So on the one hand I love that they're moving forward. Sometimes it's good to get rid of cruft (and boy is XPCOM crufty). On the other hand, the rich extension ecosystem is one of the highlights of Firefox.
I honestly don't know what I'll do if my TreeStyleTab extension is disabled. I lucked out because the Beta version has the preference to use unsigned extensions. But that extension is so fundamental to my Firefox experience that if they remove that preference in the new version then I think I'll have no choice but to turn off updates and live with my current version indefinitely. And that doesn't make me happy.
Disabling unsigned extensions without any opt-in is a terrible decision. Putting up barriers to entry for addon developers in a browser that survives primarily based on the addon ecosystem is suicidal. Addon developers do not want to run unstable alpha channel builds, they don't want to have to manage multiple profiles, they don't want to build Firefox from scratch because the version they need is not available via a package manager. I really don't care about the rest of these changes, but they need to rethink their stance on unsigned extensions.
One possible workaround would be to provide a way to add keys from which you would accept extensions. Then as part of the extension development process, you could sign your extension with your key when you are ready to install it.
If the issue Mozilla is really concerned about is security, this should be an acceptable solution.
> Addon developers do not want to run unstable alpha channel builds, they don't want to have to manage multiple profiles, they don't want to build Firefox from scratch because the version they need is not available via a package manager.
Why not use the stable versions which allow unsigned extensions?
Long time coming, the FF extensions system has been a security risk and a development burden for years. Yes, it offered unique advantages, at a significant cost though.
Judging by the number of users on Chrome, it's hardly a dealbreaker change for most. Signing & locking down extensions is a necessity. Anyone who has to deal with the user side of IT will attest to that.
You can't bury your head in the sand and expect the problem to go away or wipe your hands of it and insist users should know better. The fact of the matter is, browser extensions are one of the most common malware attack vectors nowadays and vendors should be concerned about that.
It's going to be an unpopular change amongst hard-core Firefox users and FF-only extension developers, but you can't let diehards force you to drown with the ship. They'll live and find a way. It's regular users who will happily jump ship to Chrome, Edge and Safari without a second thought.
Chrome doesn't sign extensions though, and getting them listed isn't anything more specific then a 5$ charge—how can you judge whether its "hardly a dealbreaking change" based on that?
Standardizing the basic means of browser extension is something that I've been eagerly awaiting ever since Microsoft announced that Edge will support both Firefox (Jetpack) extensions and Chrome extensions. But how will future versions of Firefox handle the extensions that just can't exist in Chrome, such as NoScript and Tree Style Tabs?
EDIT: I'm also excited at the idea that this could give Servo a running start at an extensions story, since Servo will never in a million years support XUL or XPCOM and hence all non-Jetpack Firefox addons are destined to fail there anyway.
"A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist. Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible."
So to all extension developers leaning on the current permissive features or XUL/XPCOM, please contact Mozilla and help them with finalizing their WebExtension API in the upcoming year.
Also, in the future if all XUL in Firefox is replaced by browser.html, there might be full customization options again based on html/css/js (thanks to nwah1 for pointing that out).
As a decade+ Firefox user I think this is fabulous news, not because it'll be easier for Chrome exts to come to Firefox, but because the old extension 'API' was a heap of junk and made it trivial for third parties to really gum up Firefox internals. Also huge kudos to Mozilla for not bikeshedding some new/slightly incompatible API, which I'm not sure Google would have been capable of. :)
Chrome's API is much better designed, I suppose, because they had the first chance in 15 years to actually sit down and design a modern/safe API for this specific purpose. XPCOM just exposed JS to endless unsafe internal Firefox interfaces.
We at Opera have called on for a single (or at leat a shared) API for making browser extensions, which I think will benefit the developer community immensely (instead of making one set for each browser).
It used to be that Firefox extensions could have the same capabilities as Firefox itself. It seems that this move is relegating them to second-class status.
Here's a list of things missing from the Chrome/WebExtensions API that our extension currently does:
- Customization of the browser UI beyond a single, simple toolbar button or a few other specially implemented widgets.
- Reading/writing arbitrary files to the file system. There is chrome.fileSystem, but it's limited in what it allows, and it isn't available to extensions, only Chrome apps.
- Interfacing with other applications. This typically requires using platform-native APIs, which was possible with js-ctypes (https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes). Chrome has a socket API, but it's not really the best way to do IPC, and it isn't available to extensions anyway.
- Some kind of SQL database. Firefox has an SQLite interface (MozStorage), but it's not part of the WebExtensions API. Chrome actually has WebSQL, but Firefox never implemented that (with good reason, IMO; it's tied to a SQLite and shouldn't be used on the web). I guess you'd better like IndexedDB.
- Native-looking UI widgets. This is certainly possible to do in HTML, but it's not always so easy. For example, we have yet to find any reasonable HTML-based replacement for our tree view that's both visually appealing on all platforms and reasonably performant with thousands of items. (If you have suggestions, let us know!)
I guess Mozilla's viewpoint is that, since everyone is already supporting Chrome, they don't need these things. However, for our extension, the difference between the Chrome and Firefox implementations is that the Chrome implementation needs to talk to a separate app, while the Firefox implementation can do everything itself. Firefox used to give us a very powerful toolkit for writing apps, the same toolkit they used to create Firefox. Now it looks like all we'll have is a toolkit for writing simple browser extensions.
I think many people use Firefox because they can customize it the way they want to. Soon you won't be able to customize Firefox any more than Chrome. Maybe Mozilla is banking on Servo being so fast/secure that people will use it over Chrome even when all the other advantages are gone.
The customization element was nice, but I feel like most of these issues will be addressed by future developments.
With everyone using close to the same API, we have to move backward a bit, but one browser implementing a feature like file access means developers going to other browsers and saying "Why can't I do the same thing from the other guy?"
While this somewhat exists already, it will be much louder if they aren't entirely different plugin architectures and used as a developer excuse.
That's the goal. "Web apps" are always going to be 2nd class apps, because it is insanity to allow the spoofing of the native UI. The security sandbox will always have significant restrictions, by definition. If you don't like this, write a native app instead.
> Reading/writing arbitrary files to the file system.
Are you trying to open up a massive security hole? Filesystem access is banned on purpose. Writing an extension in a way that guarantees arbitrary filesystem access cannot be exploited through some complex interaction with the rest of the browser environment is probably impossible (see: the Halting Problem). It would certainly fail in practice.
Seriously, stop treating the browser as the OS+desktop. If your platform doesn't offer any true "native" access that has the features you want, then take that up with the platform's vendor.
Well, this is all terrible. They mention having to use the nightly or developers releases instead of their walled garden versions. But both of those are unstable and very crashy. And how likely are they to keep the unbranded version up and updated as time goes on?
And getting rid of the entire firefox add-ons community is just insane. The add-ons are what makes firefox good. It's why people use Firefox. I guess if they just want us to use Chrome this series of changes will work great.
I don't have sufficient command of the English language to fully express how strongly I disagree with this. I have an extension which I made for Chrome and Firefox. The Chrome version basically consists of a single Javascript file, and a tiny json file with about 15 entries. I spent perhaps an hour to learn the basics from scratch. I don't have space here to describe all the crap I went through to get the same extension working on Firefox - and I was using their easy API. The Firefox extension development process is one of the most confusing, complicated, experiences I've ever had on a computer. Good riddance!
As someone who has written several extensions across all the different browsers (IE COM Interop FTW!!!) over the last few years, Chrome's dev experience is by far the best in my humble opinion.
Firefox's experience was hamstrung by having to learn XUL and a new and different set of tools and way of doing things. Their approval process and packaging scheme was surprisingly not as streamlined as I would have expected from them either. Chrome's experience is fairly standard and intuitive HTML, JS, and JSON interactions. In most cases it really shouldn't take too long for someone to port or migrate an old Firefox plugin to the new format.
Extensions are probably the least reason why i use Firefox. The few extensions i use are also available in Chrome. Other reasons to use Firefox (at least for me):
- It's free software.
- Uses less RAM than Chrome (when having many tabs open).
- The address bar is awesome; i can always find previous pages i visited from there without having to google them.
- It's backed up by a non-profit organization, instead of an advertisement company.
That's become my default response to Mozilla news. It reminds me a lot of what I started going through maybe 6 years ago or so with GNOME. 'Wait, what?' 'Why?' 'You've got to be kidding me!'
Why do you think they are getting rid of the community? They are (presumably) making life easier for cross browser extension developers, and the first big deprecation is about 16 months away.
We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers.
I switched to Firefox in part because XUL-based extensions can heavily customize the user interface. Things like Tile Tabs, Tab Mix Plus, and other extensions have been extremely useful to me. Despite my dislike of XUL as a language, I'm sad to see XUL extensions go; I suspect that WebExtensions will, like Google Chrome extensions, be much more limited.
In fact, I had always hoped that FF would move in the opposite direction, and split itself apart into a bundle of extensions, so that even more customization could be possible.
I've also always enjoyed being able to run the latest versions of extensions, which sometimes take a while to get Mozilla's approval.
Are there any plans to maintain a fork of Firefox that will not include these changes?
And this is how Google killed Firefox. Why do people use Firefox? For extensions. What breaks extensions, frequent updates and extension API changes.
Google managed to suck Mozilla into frequent releases and now extension API changes that make Firefox yet another generic easy to substitute browser. Wow, just wow.
"we will require all extensions to be validated and signed by Mozilla starting in Firefox 41"
I hope there is an "opt out" option to this for people who know what they are doing. I understand the reasoning behind it, but what about an extension I write just for myself that I don't wish to share with Mozilla? I don't particularly like having that option taken from me.
Yeah, I know, I could edit the source and work around it -- but based on past attempts to just build firefox, that could be a real pain.
It doesn't mention addon permissions, which I would assume is something WebExtensions has, since that's how addons work in chrome. At least I hope this is the case, lack of permissions in firefox addons is a little scary, and probably one of the reasons I have the minimum addons installed
I was under the impression that add-ons like ublock / umatrix were possible only in firefox due to its very permissive add-on model, if mozilla is going to deprecate XUL / XPCOM would it mean this kind of add-on won't be possible anymore?
Great news.
With the current system, firefox's stability, upgrade compatibility and performance were entirely dependent on every author of every extension I use being sufficiently careful. It meant a lot of periodic purges, housekeeping, and reduced trust. I'm sure the overhead helped users move to chrome, despite Firefox's vanilla install being lighter. Reducing the API surface was a necessity.
Also, it takes a lot of effort to cope with the churn in internal APIs, and I had to get rid of promising extensions like Pentadactyl because they broke too often. With a smaller, stable API, that problem doesn't exist. I don't believe that the current tradeoff of power vs responsibility was working out in the majority of cases, and I've seen enough evidence in the form of lagging addons and neglected ports.
WebExtensions is very good news. One of the biggest pains is to develop extensions compatible both with FF and Chrome so it would make our lives a lot easier.
> We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers.
This is basically the creation of a new, multi-browser API standard for browser extensions. This isn't them just adopting a single competitor's ecosystem. There is also a slim chance IE and Safari will join the plugin ecosystem.
> There is also a slim chance IE and Safari will join the plugin ecosystem.
You mean Edge. IE development is pretty much dead except for maintenance releases, and it now exists solely to handle legacy websites (read: corporate dinosaurs that rely on ActiveX).
Recent releases of Opera are just a reskinned version of Chrome. This is exactly them adopting a single competitor's ecosystem, it's just that Opera did the same thing even more completely a while ago.
[+] [-] scottjad|10 years ago|reply
"BTW, if you really want to show us that you trust this much in these new WebExtensions, the first ones to appear at AMO should be Pocket and Hello.
Remove that code from the core Firefox and put it where it always should have been: an extension that anyone interested can easily install."
And a more serious comment from a developer of DownThemAll!:
"I was thinking of abandoning add-on development for a while now, mostly because of the Walled Garden signing approach that went live, which I strongly objected to and still strongly object to… I might have come to terms with it, once I see it play out in an actual implemention…
But “deprecating” XUL-based add-ons with XPCOM access takes the cake. Once that happens, I will abandon ship for sure. Simply because I cannot continue developing most add-ons at all as they will not and cannot fit into any “WebExtensions” API. The flexibility of what XUL-based add-ons can do IS the major selling point of the Firefox add-ons ecosystem and therefore IS one of the last remaining selling points of Firefox itself that isn’t purely ideological. In comparison, the APIs that Chrome and competitors offer, that the Firefox Jetpack/ Add-on SDK offers, are just… toys.
To give a little background about myself to show that I’m not just the random hater shooting a drive-by comment: I wrote some more or less successful add-ons in the past, including DownThemAll!, and reviewed many, many add-ons as an AMO volunteer."
https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...
[+] [-] wvenable|10 years ago|reply
[+] [-] azakai|10 years ago|reply
I'm not sure if that will address that concern, it depends how far they will go with that, but at least it is clear that doing much better than basic WebExtensions/Jetpack/etc. is intended.
[+] [-] rcthompson|10 years ago|reply
[+] [-] jmhain|10 years ago|reply
[+] [-] dafrankenstein2|10 years ago|reply
[+] [-] shock|10 years ago|reply
This is very bad news for me. I'm a power user that prefers the balance of new features/chance of breakage that the Beta channel offers and I take full responsibility for the addons I install and the security decisions I make. I don't need Mozilla to be "defending" me in this case.
[+] [-] nine_k|10 years ago|reply
So I think running the Developer Edition (which I expect to be much more stable than Nightly) is probably your best bet.
[+] [-] Animats|10 years ago|reply
Whether add-on signing is part of a power trip at Mozilla to enforce a walled garden with Mozilla-favorable policies remains to be seen. When Mozilla blocks an add-on which disables Pocket or Sync or Hello, we'll know that AMO has turned to the dark side.
[+] [-] zawaideh|10 years ago|reply
[+] [-] sonnyp|10 years ago|reply
[+] [-] __david__|10 years ago|reply
I honestly don't know what I'll do if my TreeStyleTab extension is disabled. I lucked out because the Beta version has the preference to use unsigned extensions. But that extension is so fundamental to my Firefox experience that if they remove that preference in the new version then I think I'll have no choice but to turn off updates and live with my current version indefinitely. And that doesn't make me happy.
[+] [-] jasonhansel|10 years ago|reply
[+] [-] keypusher|10 years ago|reply
[+] [-] nocman|10 years ago|reply
One possible workaround would be to provide a way to add keys from which you would accept extensions. Then as part of the extension development process, you could sign your extension with your key when you are ready to install it.
If the issue Mozilla is really concerned about is security, this should be an acceptable solution.
[+] [-] dblohm7|10 years ago|reply
Citation needed.
[+] [-] TazeTSchnitzel|10 years ago|reply
Why not use the stable versions which allow unsigned extensions?
[+] [-] catern|10 years ago|reply
I really doubt Debian will flip the compile switch that completely prevents unsigned extensions on Iceweasel.
[+] [-] shinratdr|10 years ago|reply
Judging by the number of users on Chrome, it's hardly a dealbreaker change for most. Signing & locking down extensions is a necessity. Anyone who has to deal with the user side of IT will attest to that.
You can't bury your head in the sand and expect the problem to go away or wipe your hands of it and insist users should know better. The fact of the matter is, browser extensions are one of the most common malware attack vectors nowadays and vendors should be concerned about that.
It's going to be an unpopular change amongst hard-core Firefox users and FF-only extension developers, but you can't let diehards force you to drown with the ship. They'll live and find a way. It's regular users who will happily jump ship to Chrome, Edge and Safari without a second thought.
[+] [-] nightpool|10 years ago|reply
[+] [-] kibwen|10 years ago|reply
EDIT: I'm also excited at the idea that this could give Servo a running start at an extensions story, since Servo will never in a million years support XUL or XPCOM and hence all non-Jetpack Firefox addons are destined to fail there anyway.
[+] [-] micro-ram|10 years ago|reply
https://code.google.com/p/scriptno/
[+] [-] slasaus|10 years ago|reply
So to all extension developers leaning on the current permissive features or XUL/XPCOM, please contact Mozilla and help them with finalizing their WebExtension API in the upcoming year.
Also, in the future if all XUL in Firefox is replaced by browser.html, there might be full customization options again based on html/css/js (thanks to nwah1 for pointing that out).
[+] [-] _wmd|10 years ago|reply
Chrome's API is much better designed, I suppose, because they had the first chance in 15 years to actually sit down and design a modern/safe API for this specific purpose. XPCOM just exposed JS to endless unsafe internal Firefox interfaces.
[+] [-] adamc|10 years ago|reply
[+] [-] shwetank|10 years ago|reply
I think now the time is right to take a look again at NEX https://dev.opera.com/blog/introducing-nex/ and standardising core parts of browser extensions.
[+] [-] simonster|10 years ago|reply
Here's a list of things missing from the Chrome/WebExtensions API that our extension currently does:
- Customization of the browser UI beyond a single, simple toolbar button or a few other specially implemented widgets.
- Reading/writing arbitrary files to the file system. There is chrome.fileSystem, but it's limited in what it allows, and it isn't available to extensions, only Chrome apps.
- Interfacing with other applications. This typically requires using platform-native APIs, which was possible with js-ctypes (https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes). Chrome has a socket API, but it's not really the best way to do IPC, and it isn't available to extensions anyway.
- Some kind of SQL database. Firefox has an SQLite interface (MozStorage), but it's not part of the WebExtensions API. Chrome actually has WebSQL, but Firefox never implemented that (with good reason, IMO; it's tied to a SQLite and shouldn't be used on the web). I guess you'd better like IndexedDB.
- Native-looking UI widgets. This is certainly possible to do in HTML, but it's not always so easy. For example, we have yet to find any reasonable HTML-based replacement for our tree view that's both visually appealing on all platforms and reasonably performant with thousands of items. (If you have suggestions, let us know!)
I guess Mozilla's viewpoint is that, since everyone is already supporting Chrome, they don't need these things. However, for our extension, the difference between the Chrome and Firefox implementations is that the Chrome implementation needs to talk to a separate app, while the Firefox implementation can do everything itself. Firefox used to give us a very powerful toolkit for writing apps, the same toolkit they used to create Firefox. Now it looks like all we'll have is a toolkit for writing simple browser extensions.
I think many people use Firefox because they can customize it the way they want to. Soon you won't be able to customize Firefox any more than Chrome. Maybe Mozilla is banking on Servo being so fast/secure that people will use it over Chrome even when all the other advantages are gone.
[+] [-] nwah1|10 years ago|reply
https://github.com/mozilla/browser.html
Web standards are fully capable of rendering entire user interfaces now. GUI toolkits are just needless dependencies for web rendering engines.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] spaceribs|10 years ago|reply
With everyone using close to the same API, we have to move backward a bit, but one browser implementing a feature like file access means developers going to other browsers and saying "Why can't I do the same thing from the other guy?"
While this somewhat exists already, it will be much louder if they aren't entirely different plugin architectures and used as a developer excuse.
[+] [-] pdkl95|10 years ago|reply
That's the goal. "Web apps" are always going to be 2nd class apps, because it is insanity to allow the spoofing of the native UI. The security sandbox will always have significant restrictions, by definition. If you don't like this, write a native app instead.
> Reading/writing arbitrary files to the file system.
Are you trying to open up a massive security hole? Filesystem access is banned on purpose. Writing an extension in a way that guarantees arbitrary filesystem access cannot be exploited through some complex interaction with the rest of the browser environment is probably impossible (see: the Halting Problem). It would certainly fail in practice.
Seriously, stop treating the browser as the OS+desktop. If your platform doesn't offer any true "native" access that has the features you want, then take that up with the platform's vendor.
[+] [-] superkuh|10 years ago|reply
And getting rid of the entire firefox add-ons community is just insane. The add-ons are what makes firefox good. It's why people use Firefox. I guess if they just want us to use Chrome this series of changes will work great.
[+] [-] charlesism|10 years ago|reply
[+] [-] andzt|10 years ago|reply
Firefox's experience was hamstrung by having to learn XUL and a new and different set of tools and way of doing things. Their approval process and packaging scheme was surprisingly not as streamlined as I would have expected from them either. Chrome's experience is fairly standard and intuitive HTML, JS, and JSON interactions. In most cases it really shouldn't take too long for someone to port or migrate an old Firefox plugin to the new format.
[+] [-] epidemian|10 years ago|reply
Extensions are probably the least reason why i use Firefox. The few extensions i use are also available in Chrome. Other reasons to use Firefox (at least for me):
- It's free software.
- Uses less RAM than Chrome (when having many tabs open).
- The address bar is awesome; i can always find previous pages i visited from there without having to google them.
- It's backed up by a non-profit organization, instead of an advertisement company.
[+] [-] wtbob|10 years ago|reply
That's become my default response to Mozilla news. It reminds me a lot of what I started going through maybe 6 years ago or so with GNOME. 'Wait, what?' 'Why?' 'You've got to be kidding me!'
[+] [-] maxerickson|10 years ago|reply
We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers.
[+] [-] eli|10 years ago|reply
[+] [-] jasonhansel|10 years ago|reply
In fact, I had always hoped that FF would move in the opposite direction, and split itself apart into a bundle of extensions, so that even more customization could be possible.
I've also always enjoyed being able to run the latest versions of extensions, which sometimes take a while to get Mozilla's approval.
Are there any plans to maintain a fork of Firefox that will not include these changes?
[+] [-] jasonhansel|10 years ago|reply
[+] [-] super_mario|10 years ago|reply
Google managed to suck Mozilla into frequent releases and now extension API changes that make Firefox yet another generic easy to substitute browser. Wow, just wow.
[+] [-] nocman|10 years ago|reply
I hope there is an "opt out" option to this for people who know what they are doing. I understand the reasoning behind it, but what about an extension I write just for myself that I don't wish to share with Mozilla? I don't particularly like having that option taken from me.
Yeah, I know, I could edit the source and work around it -- but based on past attempts to just build firefox, that could be a real pain.
[+] [-] mrbig4545|10 years ago|reply
Anyone have more info on this?
[+] [-] fra|10 years ago|reply
I use Vimperator extensively and would hate to see it go.
Chrome does have Vimium, but it is quite clunky and limited compared to the couple of Firefox solutions.
[+] [-] tetraodonpuffer|10 years ago|reply
[+] [-] Tobu|10 years ago|reply
Also, it takes a lot of effort to cope with the churn in internal APIs, and I had to get rid of promising extensions like Pentadactyl because they broke too often. With a smaller, stable API, that problem doesn't exist. I don't believe that the current tradeoff of power vs responsibility was working out in the majority of cases, and I've seen enough evidence in the form of lagging addons and neglected ports.
[+] [-] annoyingdisb|10 years ago|reply
[+] [-] fweespeech|10 years ago|reply
> We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers.
This is basically the creation of a new, multi-browser API standard for browser extensions. This isn't them just adopting a single competitor's ecosystem. There is also a slim chance IE and Safari will join the plugin ecosystem.
EDIT:
Ty mods, this title is more reasonable.
[+] [-] amyjess|10 years ago|reply
You mean Edge. IE development is pretty much dead except for maintenance releases, and it now exists solely to handle legacy websites (read: corporate dinosaurs that rely on ActiveX).
[+] [-] makomk|10 years ago|reply