by zawaideh on 8/21/15, 2:23 PM with 295 comments
by scottjad on 8/21/15, 4:14 PM
"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...
by shock on 8/21/15, 2:55 PM
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.
by __david__ on 8/21/15, 3:50 PM
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.
by keypusher on 8/21/15, 3:25 PM
by shinratdr on 8/21/15, 5:41 PM
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.
by kibwen on 8/21/15, 2:55 PM
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.
by slasaus on 8/21/15, 4:31 PM
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).
by _wmd on 8/21/15, 5:41 PM
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.
by shwetank on 8/21/15, 3:14 PM
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.
by simonster on 8/21/15, 4:13 PM
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.
by superkuh on 8/21/15, 2:32 PM
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.
by jasonhansel on 8/21/15, 3:42 PM
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?
by super_mario on 8/21/15, 3:16 PM
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.
by nocman on 8/21/15, 3:05 PM
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.
by mrbig4545 on 8/21/15, 2:47 PM
Anyone have more info on this?
by fra on 8/21/15, 3:46 PM
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.
by tetraodonpuffer on 8/21/15, 2:48 PM
by Tobu on 8/21/15, 6:03 PM
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.
by annoyingdisb on 8/21/15, 2:44 PM
by fweespeech on 8/21/15, 2:41 PM
> 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.
by mindcrime on 8/21/15, 11:48 PM
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?
by dannysu on 8/21/15, 4:10 PM
But hopefully with WebExtension and a permission model things will get easier for getting through reviews.
by Animats on 8/21/15, 7:46 PM
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.
by amyjess on 8/21/15, 3:22 PM
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.
by neves on 8/21/15, 5:56 PM
by jaredsohn on 8/21/15, 9:24 PM
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.
by toyg on 8/21/15, 8:14 PM
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.
by ajnin on 8/21/15, 10:41 PM
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?
by thiht on 8/21/15, 8:37 PM
Thank god, this undocumented crap is a nightmare to use
by scottjad on 8/21/15, 4:27 PM
And once they kill XUL, they can kill gecko, the maintenance of which is the bane of their job.
by e12e on 8/22/15, 12:05 AM
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?
by Illniyar on 8/21/15, 6:03 PM
If this change means TreestyleTabs will not work/won't get updated, then I don't see myself continuing to use it.
by reitanqild on 8/21/15, 6:28 PM
For now I am happy someone have told me that Pale Moon exist.
by serve_yay on 8/21/15, 6:08 PM
Hmm, that sounds... bad?
by jimmaswell on 8/21/15, 7:27 PM
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.
by antman on 8/21/15, 3:12 PM
by jpatel3 on 8/21/15, 3:19 PM
by dafrankenstein2 on 8/21/15, 4:15 PM
by Nadya on 8/21/15, 4:43 PM
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?
by Aardwolf on 8/21/15, 11:45 PM
by tenfingers on 8/21/15, 3:45 PM
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.
by pekk on 8/21/15, 6:23 PM
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.