Add-ons in 2017
blog.mozilla.org
blog.mozilla.org
As the market share of Firefox is not that high, maybe extension developers eventually won't be bothered with supporting that extra version, which means Firefox extensions will be less up-to-date and there will be less of them.
That's probably a trade off they have to make, though I imagine they're aware that some add-ons won't work and that users will be annoyed by that.
Software exists to be useful. The APIs in question make it useful. The developers have been maintaining it for nearly 20 years. Their employer receives millions of dollars a year to do so.
They don't want to maintain this "burden" anymore because it's not fun to maintain old code. It's not glamorous. No one becomes a rock star by unloading the bus. But if you remove the baggage compartments, the bus ceases to be useful, and the show doesn't go on.
Chromium is such a cooler project. It was started from scratch (except for the WebKit part), and it's made by Google (which at least used to be cool), and it's got all these modern APIs. They're so great that it only took them 7 years to support resumable HTTP requests[1].
Firefox used to be about the users. Now it's about the developers. (This is not to say that individual developers are selfish, but that the organization as a whole is behaving in a way that disregards the needs of users and prioritizes the desires of the developers.)
1: https://bugs.chromium.org/p/chromium/issues/detail?id=7648. Just look at this cleverness: "In the absence of a crypto::SecureHash object, DownloadFile reads the partial file and calculates the partial hash state in a new crypto::SecureHash object. If a prefix hash value is available, then the hash of the partial file is matched against this prefix hash. A mismatch causes a FILE_HASH_MISMATCH error which in turn causes the download to abandon its partial state and restart." Any other software in the world would just restart the download. I mean, they already give it a special ".crdownload" extension, so it's not like any other program is going to mess with it. But no, they can't just resume the download, they have to make 15 hash checks and pass around 7 different objects and find every possible reason to start the download all over again. What could have been a 5-line patch turned into 7 years of waiting, a dozen revisions across 50 files...
1. The remote file has changed since the previous download, so "resuming" the download will end up combining two different files.
2. The user's computer crashed during the first download, and some of the data in the partial download was not written to disk properly. (A particularly common case: the last few blocks of the file are zeroed out.)
2. Rollback a few megabytes.
These problems were solved ages ago by most download managers.
The reason to scrape them is simple: the total API surface of XUL-based extensions is pretty much all of the internal APIs of Firefox, which means that any change anywhere in the code of Firefox breaks some extension accidentally. That's a compatibility burden that Mozilla could afford when the only competitor was IE, but it makes the development of Firefox much less nimble than that of Chrome & co. So a new, less invasive and more future-proof API is sorely needed.
1/ either try and locate all the add-ons that will be broken, get in touch with their developers, be ignored by most of them, start several weeks of negotiation with those who do answer, then eventually, several months after my code is ready, land the change, and notice that Chrome has landed that same change a few months ago;
2/ ignore the add-on developers, improve Firefox immediately, but certainly break some add-ons, hence breaking the user experience of millions of users for no understandable reason.
As you can imagine, neither solution is good and everybody suffers from either.
WebExtensions condense all the instances of 1/ into a single point of time, hoping that we never again need to go through this painful dance.
For reasons listed in other comments above, the "we will expand WebExtensions API coverage based on current add-on needs" scares the shit out of me.
I'm having visions of why I quit using Chrome because there was some download UX that could not be altered, and the default Google "one true way" of doing it irked the hell out of me.
Note that in this case, we're not discussing (only) "unsafe" APIs but also "unstable" APIs that can change from one day to the next without warning.
(emphasis mine)
And responding to that emphasis: so what?! People who use Firefox instead of Chrome do so for a reason! You're failing in two ways: 1) "breaking the user experience of millions of users for no understandable reason," and 2) turning Firefox into Chrome.
If Firefox users wanted Chrome, they would already be using Chrome. They don't want Chrome, they just want Firefox to continue being Firefox, to keep working without breaking their add-ons that make their browser theirs!
Why is this so hard for Mozilla to understand?
The day Firefox stops supporting XUL extensions is the day I stop using Firefox. I've been using Firefox since it was Phoenix. I already have Chrome installed--I'm not using it, and there are reasons for that. You should meditate on this.
Mozilla is slowly committing suicide. It's painful to watch, because it doesn't have to be. One of the great forces in the Internet's history is not going to be around in a few years. Firefox will live on, because of the MPL. But what a shame to destroy the organization that brought it into being. Such a waste.
Oh well. If the Internet has taught us anything, it's taught us that, when it comes to software, developers are fungible. The phoenix will rise again.
Presumably he's talking about web features when he says "Chrome landed that change a few months ago". This isn't copying Chrome, this is web compatability. You need that for websites to work.
In any case, you certainly don't speak for all Firefox users.
So far, Firefox did not even manage to reach chrome parity, let alone bug parity.
If you look at the Advisory Group meeting notes (in charge of new APIs AFAIK), there is almost nothing still: https://docs.google.com/document/d/1qCIUX0LavYixkzwan8IcSYeu...
Sorry David, but you're kidding yourself here.
Developers and users are also concerned about add-ons being prevented from exploring radically new concepts which would require those "super powers" apparently taken away by the WebExtensions API.
I'd like to reassure them: Mozilla is investing a lot of resources to ensure that complex and innovative extensions can prosper also in the new Web-centric ecosystem. In fact, as mentioned by Bill McCloskey, at this moment I'm working within Mozilla's Electrolysis team and with other add-on authors, involved in the design of mechanisms and processes helping developers experiment in directions not supported yet by the "official" the WebExtensions API, which is going to be augmented and shaped around their needs and with their contributions.
https://hackademix.net/2015/08/22/webextensions-api-noscript...
That comment by Giorgio (nice guy btw, shared a room with him on at a couple of mozilla events) is over a year old by now and rather optimistic. So far, nothing of that happened, nor will it ever happened at a scale that actually accommodates most add-on developers.
He wrote that it was already happening a year ago: at this moment I'm working within Mozilla's Electrolysis team and with other add-on authors, involved in the design of mechanisms and processes helping developers experiment in directions not supported yet by the "official" the WebExtensions API
I'm not an add-on developer but I've read about it happening in other places too, and I know for a fact that Giorgio is working on Firefox WebExtensions issues in Bugzilla.
I don't know how you come to this conclusion. They've been able to maintain XUL up until now and whatever they end up with in this new API, it'll be cheaper to maintain than the monstrosity that is XUL extensions.
The specification and implementation are done in cooperation with the add-on developers. They can draw from the community here.
And while they haven't reached Chrome parity yet, they do have already implemented some additional APIs. You're writing as if one thing would block the other.
PS: As to maintaining XUL vs WebExtensions API, they always maintained XUL/XPCOM themselves because that's what Firefox itself uses, meaning the entirety of Firefox developers "maintains" that "API". They regularly broke stuff for add-on developers, which was sometimes annoying, sometimes avoidable, and other times just necessary.
Some add-on developers learned to adept to that, other add-on developers switched to the add-on SDK (which like WebExtensions is a limited API, just not chrome compatible) if it was feasible, and a lot of developers will switch to the WebExtensions API if feasible in the future or even now.
But that's also what makes them more powerful than any other extension API.
If your box is airtight then there is no out-of-the-box thinking.
An almost trivial example: Internal APIs can inspect the current (as-enforced) sandboxing flags of an iframe. Which is not the same as the sandboxing HTML attributes on the frame, because those can be changed without effect after loading and also due to inheritance of sandboxing effects.
This tiny tiny tidbit is useful when making content-filtering decisions.
And it is just one among countless others.
I don't remember specific numbers, but I seem to remember that pretty much all the extension points that had been requested by add-on developers were at least somewhere on the TODO list of WebExtensions. I hope that by the end of 2017, they will all be available, with a much cleaner API than their XUL/XPCOM counterpart, better tests and much better survival chances.
Of course, some of the changes will require pretty drastic reimplementations by the developers. For instance, going from js-ctypes to the native bridge will require full reimplementation in a different programming language. On the upside, js-ctypes was really painful to use and the native bridge will let you use a much better language for the task. Say Rust :)
js-ctypes allowed an addon to access already-present native libs on the the host machine or bundled with the addon itself. Messaging only works if you can get users to install some external application in addition to your addon, which is a too-tall hurdle for small extensions.
From my perspective those barely comparable.
> That's one of the reasons the WebExtensions team has been very actively discussing with add-on developers to try and prioritize which APIs should be created/ported to WebExtensions.
You are taking requests to keep existing uses supported, mostly for big, already established addons. My concern extends beyond that. Simply by having access to internals anyone can currently develop novel uses, even if they initially do not have a userbase. Those can only be prototyped by access to internals. Someone might not even have an idea if they don't know an API exists that could be leveraged to do it.
In other words, "I can't let you do that, Dave" API design can stifle creativity.
And it also introduces a bias in favor of already entrenched extensions, which is less open than the current approach.
I haven't checked, but I seem to remember that you can provide a platform-specific binary as part of an add-on, spawn it from WebExtensions and then communicate with it through the native bridge. Building/shipping one binary per platform is annoying, but the rest is infinitely better than using js-ctypes. I should know, I've been one of the first users of js-ctypes and I still shudder at the thought :)
> In other words, "I can't let you do that, Dave" API design can stifle creativity.
True. On the other hand, this is the kind of paradigm shift that was implemented by operating systems ~20 years ago (more in the case of Unix) and so far, improving the safety and security of operating systems has generally played in favor of users and creativity, not against them.
This doesn't mean that there is no space for lower level, MS-DOS/Apple II-style hacking – I'm doing exactly that these days. But still, separating both sounds like a good idea to me. YMMV.
> And it also introduces a bias in favor of already entrenched extensions, which is less open than the current approach.
Good point. I seem to remember discussions about how to have an "unsafe" extension mechanism that would make it easier to experiment with non-standard APIs. I haven't checked myself, but I believe that this mechanism has been published, as an extension called "the WebExtension Extension" or something like that.
What? No. Every OS out there allows the loading of user (administrator) supplied code to increase it's functionality.
In other words, every OS out there allows extensions that touch their internal APIs (or a very permissive subset of them in the case of Windows, that is known by how restrictive this is).
No. Kernel modules can be installed at runtime. The user just has to grant the application the necessary privileges.
This means OS developers do not try to attempt to "strike a balance" between power and safety. They allow both, the unsafe stuff merely requires a fairly simple opt-in.
This is the whole crux of the issue. I do not mind security measures, as long as there is a bypass. Mozilla has taken the - in my opinion extremist - position that even bypasses cannot be allowed because they know what's best for users.
> I haven't checked, but I seem to remember that you can provide a platform-specific binary as part of an add-on, spawn it from WebExtensions and then communicate with it through the native bridge.
I am not aware of any such feature. This used to be true for bootstrapped extensions, but not for webextensions.
> I haven't checked myself, but I believe that this mechanism has been published, as an extension called "the WebExtension Extension" or something like that.
yes, only works on dev edition though.
So for the foreseeable future, servo is not an alternative to replace XUL/XBL anyway. mozilla said that themselves.
Using servo to render the actual web pages inside the browser, that's another matter (once servo is considered stable enough, of course). To the add-on developer, this should not really make any difference anyway, XUL add-on, SDK add-on or WebExtension alike, as most add-ons for the most part will use the regular DOM APIs which servo has to provide anyway to interact with web stuff.
It's definitely the case that the Firefox UI very much makes it impossible to move away from the current layout implementation at this point, and moving away would be a massive job. At the same time, the Firefox UI cannot move away from XUL/XBL until extensions no longer have free access to it, so this is definitely a first step that's relevant here.
As for using Servo for web content, it's worthwhile pointing out that not only is it the direction Mozilla is taking (with Project Quantum, and progressively moving components from Servo into Gecko), but it would also be a technical challenge because web extensions have access to extra APIs and have security checks disabled in others.
But those developers that cannot or will not use WebExtensions (e.g. I will not/can not port most/any of my add-ons incl. DownThemAll!), but probably would manage breaking changes (I did that for more than a decade now), are left in the cold, rainy dark now.
So to fix this they're going to break every extension.
I think it's a fair assumption given how long the current extension API has been around that there will be more extensions that will die to disinterest or inability to move to WebExtensions than have been broken by all firefox releases from 4.0 to date.
I'm with you. We should start moving to Pale Moon before the end comes.
So it was less of providing a poor api like Chrome and more like creating a newer and better API that also happens to be a superset of Chromes API.
A few years ago, I switched to Firefox for precisely the set of features they've axed. It was also much faster than the alternatives for me, used much less RAM, and rarely locked up. Since then, I've seen performance decline, RAM usage ramp up, and watched the browser lock up nearly once every hour. At this point, I'm probably just gonna go to Chrome. What's the point if Firefox is just gonna be a shitty clone?
Very relevant to this thread, addons and plugins are a huge cause of poor performance - I ran into this a while back, where an addon was leaking memory via zombie tabs. Have you tried disabling addons?
Also if you find firefox to be slow, try it with addons disabled (firefox --safe-mode).
Thats what they want to fix by getting rid of XUL, among other things.
So I decided to leave the platform and put my efforts on native and web and frankly it was a good decision.
The WebExtensions API is no match to XUL and XPCOM but I only hope that now that we have Mozilla behind the technology we will see further API improvements.
For the sake of curiosity, did you create extensions as side-projects/startup ideas? Do people pay for extensions or are we talking about patreon funds here (Or startups like pocket whose extensions are ways to get more crowds).
Based on my experience, I can only advise not to base your entire business model on browser extensions as you will become dependent on platform moves (again unless enterprise).
I'm curious about my mains:
- Classic theme restorer
- uBlock
- DownThemAll
- Markdown Here
As I'm already using electrolysis, I know Markdown Here basically doesn't work. How I can check whether things will break or not.
I think the real issue is that innovation in the extension space is effectively over - the Firefox extension system is so vibrant because anything was possible. Now Mozilla is reducing the possibility space to that which is provided by the much more limited WebExtensions and adding in support for existing popular extensions. But new extensions, doing things yet undreamed of, will no longer be possible.
I'm not sure what the distinguishing features of Firefox will be moving into the future. More and more, I think it's becoming Just Another Browser, with a better ideology behind it. Well, that's not a winning formula. I'm really disappointed and I don't know what to do other than stay on old versions of Firefox as long as I can.
http://www.downthemall.net/downthemall-3-0-5/
“After a rather long long time, with many new things to address such as Australis, e10s, limited time we could spend on the project, a little lack of motivation after mozilla required mostly pointless signatures and announced to kill XUL add-ons…” - Nils, September 2016
"Just to clarify: We did not port it to the WebExtensions API, nor do we think it is possible to port it in any significant manner to the WebExtensions API..."
https://addons.mozilla.org/En-us/firefox/addon/downthemall/r...
I communicated to the mozilla people who got in touch with me that there will not be a crippled DownThemAll!, at least not from me.
The DownThemAll devs have been very vocal about "WebExtensions being the likely end of DownThemAll", although I don't know if due to understandable unwillingness to redo a lot of their work or actual technical limitations.
Classic theme restorer probably relies on XUL/features unlikely to be re-implemented, see dev response to this review https://addons.mozilla.org/de/firefox/addon/classicthemerest....
Ironically the long-term ideas of having a HTML based GUI could enable heavy modification again, at least in modified "distributions" of FF? Doesn't solve the now/next year though :/
To elaborate: If you're doing "web stuff", toolbar buttons, and request stuff (adblocking etc), you'll probably be fine. If you're lucky enough that you only need a few additional new things and your name is e.g. Giorgio of NoScript, you also will be probably fine.
If your add-on does not have a sizable user base, and you do fancy things like modding the browser UI itself, or doing something else not entirely "webby", your outlook is a lot less rosy.
But yeah, I'd just like to say that in case you did not do your best to maybe get to a solution with the Mozilla devs, that I'd appreciate it, if you could try again.
I don't personally use your add-on, but I know that a lot of people do and I think that this initial discourse to get some of the APIs sorted out is rather important.
Even if you don't end up writing the extension, it'd be good to have reasonable APIs at least drafted. So that maybe someone can offer a half-assed Down Them All, which maybe is already good enough for some people, and then maybe that add-on's developer can continue working with Mozilla to get a proper API fully sorted.
You should also consider that Mozilla started out with this "webby" state from Chrome. Anything modifying the UI and so on still needs to be defined. Once they have some of the other UI-APIs worked out, it'll be easier for Mozilla to fit new libraries into there and then it'll also be easier for Mozilla to work with your API needs.
I'd really like to share your optimism here, but really, knowing what I know, I just cannot.
For me, if DownThemAll isn't one of them, I'll either stay with the last compatible version of firefox or, more likely switch to one of the alternatives that does support it and the others that have become such an integral part of my browsing behaviour.
I've been burned so often by the changes made in recent years, so much so that I have next to zero loyalty to them anymore. And I've been using firefox since the browser was still part of the Mozilla suite.
You can try yourself: either install https://nightly.mozilla.org/ and load it with your addons (it uses different profile) or use your stable one and look at about:support page for "Multiprocess Windows" cell if it states 1/1 and does not mention "(Disabled by add-ons)" you are covered. You can try some about:config alterations [0] to force it if you are adventurous. In this case, it might be nice to install "Add-on Compatibility Reporter" [1] for tracking and sharing your findings.
[0] http://superuser.com/questions/1096974/how-to-check-if-multi... [1] https://addons.mozilla.org/en-US/firefox/addon/add-on-compat...
The guy seems to be confusing things here, too.
But while this doesn't confirm it, it neither confirms the opposite. So, it is very much still possible thst Tab Mix Plus gets ported to WebExtensions before the old add-ons get shut off, i.e. you might very well be able to use it still then, there's just currently no way to know yet.
And as far as I can tell, the developer seems to have accepted porting it to WebExtensions and will most likely do it: http://tabmixplus.org/forum/viewtopic.php?f=1&t=19282
As I understand it WebExtension is inherently multi-process compatible so (to answer question below) the only extensions we know today will work next year from arewee10syet.com are those marked as "compatible-webextension".
[0] Most of extensions I'm used to alters chrome visually or functionally: calls external applications, changes hotkeys, so almost none of them are XUL-free. But I still hope / believe Mozilla is not that insane and will achieve consensus keeping the most important features for extensions authors available in the end.
FYI, uBlock is abandonware[2].
[1] https://github.com/gorhill/uBlock/releases (search for "webext")
[2] https://github.com/chrisaljoudi/uBlock/releases ("released this on 31 May 2015")
As a user of, not developer for, Firefox with its extensions, it's this simple for me: The day my existing extensions stop working -- the day neither they nor an alternative under the new paradigm offer equivalent functionality -- is the day I no longer have any reason to stay with Firefox.
I'm not saying, "Stop, wait, a user is unhappy!"
I'm simply saying that, as a perhaps sophisticated user with some more advanced functionality, security, and privacy concerns, the set of extensions I currently use is my only compelling reason for using Firefox over Chrome.
Well, that and Google/Chrome's current trend towards its own version of Embrace, Extend, Extinguish wrapped within a panopticon.
I embrace the browser as the user client. I'm glad to have security issues addressed, but I also require that the browser do what I want, and not what -- a la Chrome, for example -- media interests want to dictate.
I'm watching 2017 with trepidation, and wonder whether and when something may fork. Not unrealistically, though; I'm skeptical any fork is going to have the resources and commitment to maintain a modern, full-featured browser in the face of current and future... err, developments.
Maybe such a fork will, both of desire and of necessity, look instead towards a bit of minimalism. Not doing "everything", but doing core functionality well and securely.
I guess then we'd have to see whether the content farms with their Javascript++, DRM delivered content, end up leaving such a fork too much out in the cold for it to maintain sufficient interest and/or usefulness to keep itself going.
If not, then say hello to people staying with firefox 56 for years.
There are some hacks that open a new window with tabs, and resizes the main window to put it side by side, but it doesn't feel right.
Or at least that was the case the last time I looked a year or two ago.
Edit: also, yes, from what I understand, the WebExtenstions Api in Chrome does not allow these modifications.
¹keyboard goodness: https://github.com/The-Compiler/qutebrowser
Some experiences:
a) Copying HN links doesn't work. All you get in the clipboard is "/item".
b) Google Drive is utterly unusable.
c) Facebook is mildly unusable. Rendering gets easily messed up.
d) No password management.
But these are fairly minor, I'm happy to use a secondary browser for them.
How does that free webpage to PDF converter add-on make money? By selling your web history of course.
[1] https://www.google.de/amp/thehackernews.com/2016/11/web-of-t...
EDIT: added OT tag
If the browser is able to eat my RAM a bit less, I would be quite happy to have my add-ons off for some time.
Based on Mozilla's track record, that's too soon. It took about three years after the announcement of the Jetpack API before it worked right.
"Open in Browser", which allows ignoring "content-disposition:attachment" to display pdf/image/txt in browser rather than save to disk
"Android Text Reflow", which allows wrapping text to fit the screen on Android after zooming in on a web-page
"Status-4-Evar", which adds back the status bar at the bottom of firefox
Thanks!
As someone working on another free software project with an aging code base, we see this debate all the time: limited funds, limited interest to maintain the old core, but users rely on it. However, users also want performance improvements, more reliability, new features... not to mention what do you do when security issues pop up. At some point you need to cut your losses and find a model easier to maintain.
Could be some kind of effort to fork the code and have users who care about Firefox rally around a non-hobbled version?
Because scripts are stored in a database, TamperMonkey does not play swimmingly with GIT either. Finally, TamperMonkey is a third party tool that from time to time asks for money. GreaseMonkey is open-source.
The TamperMonkey EULA:
Your right to use Tampermonkey continues until terminated by the Company, which may terminate this Agreement and your license to use Tampermonkey at any time, without cause and without notice. You may terminate this agreement at any time by uninstalling Tampermonkey. This Agreement will automatically terminate if you fail to comply with any of the terms of this EULA. Upon termination, you agree to stop using and to uninstall Tampermonkey.
I think this will be good in the long run--Zotero is complex enough to merit being its own application, and separating Zotero and browser plugins will make it easier to migrate Zotero off XULRunner at some point, if the developers choose to do so.