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.
The end result is that Firefox users have a much wider array of add-ons to use (despite the add-on system being somewhat crazy by today's standards).
New, simpler addon APIs are fine, but not when they replace more powerful ones.
I guess that it's inevitable that Firefox has creeped from a "power user browser" to a dumbed-down maintstream one. I guess it's time to start looking for a new power-user browser.
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!'
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.
They're getting rind of those people who are willing to dive deep into the internals do develop something that nobody thought of before (if they did there would be high-level APIs for it).
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.
So I think running the Developer Edition (which I expect to be much more stable than Nightly) is probably your best bet.
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.
Unfortunately hoops aren't enough to fix this problem, because hoops generally involve some flag that you've gone through the hoop, and the installer can easily fake that.
now you say release/sign your extensions.... well they mostly contain internal data and URLs. no way I'm publishing any of those.
"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...
Also the main reason why I use Firefox as well... This window has 20 tabs open :)
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.
I don't think I'm overly pessimistic. Apart from having been in the game since mozilla suite and having experienced a LOT of things that didn't turn out so well, to say the least and keep it polite and curse-word free...
The WebExtensions API is supposed to be an intentionally strictly defined API with a limited feature set; that just comes with the territory. It is supposed to give you access to a subset of Firefox features/internals. Compare that to the current extension "API": What Firefox can do, your add-on can do, and a lot of more things as well. You can customize Firefox to the point it really is a new browser (with thinks like Tab Mix Plus, Tree tabs, vimperator/pentadactyl) or just keep it (almost) vanilla, as you please. This is a major plus for users.
Sure, for a lot of things the extension team may add a WebExtensions API. But that is limited to what that team deems worthy of their time, deems "useful", and deems "safe". It is no longer up to the add-on developer to decide what they would like to develop, but up to the WebExtensions API gatekeeper team on what they want to allow and what they then prioritize and create the actual APIs. Adding new APIs you may need will require you nag the team about it, though luck if you don't speak any language they understand, tough luck if they don't care or cannot care because their time is not infinite.
What makes me even more pessimistic is seeing the Jetpack/Add-on SDK after years of development and how it still only can address only the most basic use cases. The number of SDK-based add-ons, even relatively simple ones, that have to resort to 'require("chrome")' is staggeringly high. If the pace of the Add-on SDK and the stability its API is any indication... Time to look for another browser... Except there isn't any comparable to what Firefox still is right now.
And let's not forget: A change like this will break almost all existing add-ons in major ways. Many if not add-ons need to be rewritten in their entirety or at least in major chunks from scratch. Many add-ons will simply not make that huge investment in time required for that and simply die, without readily available replacements and leaving users behind scratching their heads.
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.
> If the issue Mozilla is really concerned about is security, this should be an acceptable solution.
I don't know what you're implying here. That they're not concerned about security? What are they concerned about?
Then malicious apps will just sideload new keys.
Citation needed.
Why not use the stable versions which allow unsigned extensions?
I really doubt Debian will flip the compile switch that completely prevents unsigned extensions on Iceweasel.
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.
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.
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.
If Mozilla wanted to go the standardized API route, they could have done that initially instead of introducing the Add-on SDK (Jetpack). IMO, that would have made more sense.
And if they wanted to, Mozilla could still allow XUL/XPCOM add-ons to coexist with WebExtensions add-ons until Firefox itself stops using XUL/XPCOM (which will most likely happen when Servo is ready for prime time). And by that time, maybe they could standardize js-ctypes as part of WebExtensions, which would address the middle 3 issues on my list.
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.
Firefox extensions run in a privileged context. They essentially are not really different from components of firefox itself.
Firefox components can obviously access the filesystem. So can extensions.
An extension in itself is not any more a security hole than firefox itself.
> Seriously, stop treating the browser as the OS+desktop.
While I agree with you there, what's needed to get to that point would be browsers actually talking to the native environment more. Pipes, sockets, filesystem access (chroot-style) even limited process launch capabilities.
If web or extension APIs allowed that it would be far easier to integrate with native instead of having to build it straight into the browser.
But that just addresses the "app" kind of extension.
Other extensions instead customize the web browsing experience. For example if you have a file form and want to do automation (filling in the right files?) then you already need access to the file system. This has nothing to do with native apps and yet needs access to native resources.
You're right that it's insanity to allow a web app to spoof the native UI. But extensions aren't web apps: they are native (or should be).
Extensions are extensions to the browser: they're what can actually provide secure crypto and privacy.
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?
Alternatively, maybe https://github.com/breach/breach_core though their website is down, so maybe the project is dead...
Here are some: - FireGestures (mouse gestures) - NoScript (it can do much more than the Chrome equivalent) - SecureLogin (wand-like behavior from Opera; basically instead filling login and password after page loads it logs you in after pressing a button) - Tab Scope (thumbnail of webpage when you hover over a tab) - Tree Style Tabs (it does what the name says) - Informational Tab (this I can live without, but I like it, it puts progress bar in the tab which looks nice)
This news sucks, first Opera 12 was discontinued and replaced with Chrome with different skin. I finally moved to FF and used multiple extensions to get some of Opera functionality back and now those are going away.
Addons like Fire Gestures and Easy Dragtogo are what keep me on Firefox. Chrome can't implement those apparently, and now it seems that support for them will be deprecated too.
> 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.
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).
The title now is just spin.
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.
http://blog.chromium.org/2015/05/continuing-to-protect-chrom...
Each vendor is moving at their own pace and in their own way, but the endgame is clear. With that comment, I was also referring to the depreciation of XUL more than the signing requirement.
> 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.
Fewer people might need the flexibility, but Mozilla effectively dictating the browser experience still seems excessive. Comparing it to Windows, it's almost akin to Microsoft requiring signatures on all software that can be installed.
Anyone have more info on this?
In a strikingly similar parallel dimension, vendors have applied pressure to ensure that networked PCs would only run COBOL, and other languages could only be supported by compiling to a subset of COBOL that inherited its semantics so that nothing would ever be faster than COBOL. In that parallel dimension, this restriction is known as "Open Web", although nobody knows what is open about it.
It's not about that. Even if I liked COBOL, I wouldn't want a world where only COBOL can be used. And it doesn't make sense that this world has to be artificially enforced when there is demand for variety.
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.
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.
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.
Secondly, in order to achieve its goal, it's relying on a hack:
...
if (getElSrc(this) && getElSrc(this).toLowerCase().substr(0,11) != 'javascript:' && getElSrc(this).toLowerCase().substr(0,17) != 'chrome-extension:')
...
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.
The impression I get is that Mozilla wants to be more involved in the user experience around their codebase, but personally I preferred firefox's lack of involvement. I think the UI is poorly designed and getting worse, but as long as it was easy to modify, it wasn't an issue. The real value in firefox for me is gecko. Most other things largely get in the way, and it seems like that's what's becoming the focus.
I can understand the need for a better designed add-on API, but there should probably be a non-compulsory reason for people to switch.
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.
I honestly don't remember any other browsers that have the Mozilla branding removed, but I haven't really tried to find any.
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.
> I don't believe that the current tradeoff of power vs responsibility was working out in the majority of cases,
For me those tradeoffs are worth it. Sometimes it means installing a beta builds of an addon or nagging its developer on github or even finding a replacement. But that's still better than not having the addons at all because the APIs simply make it impossible to have them in the first place.
If mozilla separated addons into "uses stable APIs only" and "might break at any time, we may even turn them off if they cause to many crashes" that might allow users to choose which kind of model they want to follow.
However, giving it more thought, I think this might actually be a Good Thing in the long-run. OK, it's a stretch, but hear me out... I've been a vocal opponent of this whole idea of making the browser a poor man's operating system for a while. I want a Web where browsers are really good at, well, browsing hypermedia, and other applications handle "application stuff". So maybe, in a roundabout fashion, making it a little bit harder to extend the browser even further, will encourage people to shift back to a model of handing off some kinds of requests to an entirely different app, rather than trying to shoe-horn the kitchen sink, bathtub, 3d printer, milling machine, jumper cables, semiautomatic pistol, bandsaw, swimming pool, and clown suit all into the browser.
Or maybe not. Hey, a guy can wish, right?
A more interesting question might be: "What would it take to slow down this movement towards doing everything (and then some) IN the browser"?
That's so Mozilla. There's a long history in add-on development of Mozilla deprecating the old thing before the new thing works.
XUL/XPCOM had to go. The mobile browser, "Fennec", doesn't use it at all.
But the "Jetpack" API, the one Mozilla wanted everyone to use instead of XUL/XPCOM, is apparently being deprecated as well. The announcement says it will "continue to work", but the new API seems to be completely separate from Jetpack. That probably means bugs in Jetpack won't be fixed, and bug reports will be answered with "convert to (new thing)".
Mozilla AMO. Embrace the pain.
It would have been nice if they had learnt their lesson and actually started communicating changes after they had something real to show, but alas, it seems like they're doing the same thing, just a little bit faster (maybe).
Yes, and now that it pretty much works, after years of bug reports and nagging to get bugs fixed, they're deprecating it.
One thing I don't see anything about wrt extensions is user control. If ff is to remain relevant - signing extensions will need to come with a trust management framework. I might want to run extensions signed by Debian and myself - but not mozilla (in iceweasel). RedHat (or other vendor) might want their unbranded ff fork to only use RedHat extstensions by default; maybe with an option to also allow upstream ff signed exstensions.
Without that; I see no point in signing support in a free software product?
https://billmccloskey.wordpress.com/2015/08/21/firefox-add-o...
Hmm, that sounds... bad?
I've disabled updates in FF.
Palemoon removed Tab Groups and the addon is extremely buggy and doesn't restore properly when the browser crashes. Waterfox had several issues with plugins I use.
I guess it's time to fork FF and maintain my own version, implementing security patches as they come in?
AKA Iceweasel?
GNU IceCat could also be an alternative along the same lines, and I know for sure that IceCat can be compiled on Windows and they distribute a Windows binary.
The only problem being GNU IceCat doesn't seem to work on my work computer..
I'm even _already_ running an "unbranded" firefox in all my devices (iceweasel, fennec), for the same reasons I have to run chromium, so I won't even be _directly_ affected....
But there's only one thing I really want to say to Mozilla right now, as a developer:
Fuck you Mozilla.
And there's another, as an user of which most extensions are unsigned:
Fuck you again, Mozilla.
aaah feels better.
But maybe that won't be necessary anyway. By adopting a very limiting standard for extension development and dropping xul (which might be a good idea for other reasons though), there won't be any significant difference between firefox and (say) chrome. A few tweaks in the browser frame won't attract masses of people. Switching from Chrome to Firefox on Android require a pretty big incentive.
Right now, I'm on firefox only for the extensions. I have really no other compelling reasons.
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.
I use a number of extensions that extensively modify the UI (e.g. Tab Mix Plus), and honestly I'd rather just stick with an older version of Firefox than use Firefox without these extensions.
Quoting from the announcement:
> 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.
Does anyone know why they are calling this API Blink-compatible rather than Chromium-compatible? My understanding is that Blink is just the rendering engine and extension code can be found within the main Chromium project.
My best guess is that they are referring to it this way since I think that currently the list of browsers that use Blink is the same as the list of browsers that use Chromium code and people are more used to categorizing browsers based on their rendering engine rather than where the code originated.
That's a good question, since the two sources they link to (from Chrome and Opera) both refer, directly or indirectly, to Chromium extensions, and neither refers to "Blink" at all.
This is relatively "mitigated" in the case of add-ons because backwards-incompatibility has become the norm so old add-ons are likely to break anyway at some point, but this still seems like a very bad idea for Mozilla to kill a large portion of their ecosystem in that single move, especially if in the bunch are very differentiating extensions like Tree Style Tabs.
Justifying the decision by becoming even more interchangeable with Chrome is especially baffling, what is the strategic point of this?
That's not the case for Firefox's migration: WebExtensions are easier to write and work with other browsers.
And once they kill XUL, they can kill gecko, the maintenance of which is the bane of their job.
We've identified that XUL is a growing impediment to Firefox's continued success. Exactly what that means (there are dozens of reasons and dozens of ways forward), and how we're going to tackle it, is a big topic that we're digging into.
Yes, removing XUL implies that XUL-based add-ons are not going to last forever. That doesn't mean there won't be a path from here to there: everyone involved recognizes that add-ons are important, and we're increasingly going to be shipping parts of Firefox itself using add-on mechanisms.
And I haven't seen anyone seriously consider killing Gecko: it continues to be awesome, and one of the motivations for deXULification is to allow our platform developers the freedom to only focus on supporting HTML UIs, not a mix of HTML and XUL.
Also, I wonder if it's still slow if you restart with extensions disabled. There's a lot of hidden interactions in the current model.
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).
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.
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.
But hopefully with WebExtension and a permission model things will get easier for getting through reviews.
How can you tell your own developer community "what you're doing now, it won't be allowed next year; but what will be, we don't know yet"? You might as well tell them to go home.
Thank god, this undocumented crap is a nightmare to use
If this change means TreestyleTabs will not work/won't get updated, then I don't see myself continuing to use it.
For now I am happy someone have told me that Pale Moon exist.
This comment hit the nail on the head.
Really in general the browser vendors are all killing the web day by day. Maybe ~2004 to around 2013/2014 or so will be remembered as the golden age of web browsers. NPAPI worked in major browsers, you were allowed to install extensions without Mozilla or Google's permission, and Firefox had yet to mutilate its interface in an attempt to be a Chrome lookalike.