So killing off XUL is great and all, but two of my favorite add-ons [1] [2] are already planning to call it quits because the Web Extension API likely won't be powerful enough. Tree Style Tab isn't far behind, I'll bet. These add-ons are the reason I use Firefox.
It seems like Firefox is going to become just another browser.
I really want to be on the authors' side here, but both posted very vague "new api is coming, stuff won't work". Where are at least the links to bugzilla where they request appropriate bits in extensions API to be implemented? This seems very short: https://bugzilla.mozilla.org/buglist.cgi?component=WebExtens...
For all the outrage about extensions not working in the future, I've not seen one blog post about a proposed api which they need and which was rejected.
<Firefox> New API coming. You'll have to rewrite your add-ons for sandboxing, etc.
<Add-on Dev> Oh, okay. -_-
<Firefox> By the way, the APIs aren't all there yet, so what do you need?
<Add-on Dev> Yeah, forget it. I've other things to do.
Both sides are reasonable. Firefox needs this to move forward, but there's only so much effort that people are willing to put into it.
I do hope that Web Extensions will become powerful enough to make the great add-ons we have now, but I'm afraid it's not going to be a nice ride.
Oh come now, that's not fair. Sure XUL can't be the key to a good extension mechanism. If devs stop writing (or choose not to port) it's because of the economics of Firefox extensions, which is to say, there are no economics to writing Firefox extensions. Except some minor reputation points and feel-good points. (The exception, of course, being those add-ons that make a SaaS more usable.)
Out of curiosity, if there was a Firefox App Store, how much would you pay for Tree Style Tabs?
From what I understand its not for lack of commitment that these extensions arent porting, its because XUL had basically the ability to run native code and modify everything.
That is the new web extension api does not replicate all the features of XUL (by design).
Look at the sorry state that is Tree Style Tabs clone in chrome - which is because Chrome's extension api is just not powerful enough.
I would pay a significant amount of money for pentadactyl + Tree Style Tabs that just worked, without bugs. It's a significant part of my workflow, and I'm not sure if either will survive XUL deprecation. :(
It's not about XUL, it's about having no limit on what you can do to the browser.
Old-school extensions can change entire parts of the browser, remove features, there really is no limit because the extension code is dumped inside the browser code without any kind of interface or security limitation. So it's powerful, but potentially destructive as a bug in an extension can impact the whole browser, and same goes for performances.
On the other hand, the new API is more like Chrome where you have defined entry points to plug your extension.
The new API approach has limitations, but it's a much better way to do extensions. Not only it limits the damage a poorly written extension can do, but it will make extensions more robust to version upgrades of Firefox.
Well according to Mozilla TST has 100 000 users. At a few bucks that's 300 000$ I suppose that could be enough :) With that money you can even maintain a separate Firefox patch-set to allow the plugin to work.
> there are no economics to writing Firefox extensions.
The same could be said of most free software. But see [1].
> Out of curiosity, if there was a Firefox App Store, how much would you pay for Tree Style Tabs?
I don't know. I keep dozens of tabs of reference materials open at work, which becomes unmanageable without it. I'd either pay for it, find a new way to work, or build my own.
Apropos of nothing it occurs to me that one way to make it lucrative to build totally open and freely distributed software is to invent a caustic software environment. E.g. keep changing the hardware and software dependencies so that anything you did build and give away has to be built again. And again and again.
That's one way to make a living from software in the long term, but it sure does seem wasteful. And if the technology truly hits an asymptote, then it's not clear what will drive the decay apart from programmer self-interest.
It would be pretty awesome if we can get to a place where browser extensions are truly cross-browser. At least for some definition of "browser extension".
I'd be OK with a "common core" that's cross-browser, and the browser makers continuing to support their own extension APIs as well, IF the "core" API never becomes as powerful as the old, native APIs. I'd hate to see the native APIs go away completely though, as I don't like the idea of artificially restricting the range of possible plugins.
Then again, I am already annoyed by Chrome ditching NPAPI and leaving us in a place where, AFAIK, you can't run the Java plugin in Chrome. OTOH, JWS still works (I think) which is something at least...
Java is still required for a lot of educational gizmos online (like physics demos/examples). Hopefully there'll be an effective way to keep such things alive "in this day and age".
Nor can you integrate with the local filesystem, or call native APIs. With a hidden Java applet, it was pretty easy to make a full-fledged application that just happened to have a web-based API. That's getting a lot harder.
Chrome extensions have an API called Native Messaging which is roughly the postMessage API over stdin/stdout. It works, but isn't cross-browser. Alternatively, you can start up a local server and make XHR or WebSocket calls to localhost. However, both of those require the user going through an external install process. Maybe, in the current security landscape, that's the way it has to be, but it's kind of annoying.
>It would be pretty awesome if we can get to a place where browser extensions are truly cross-browser.
Yes, yes, yes!
There is absolutely no reason why this can't be done. And, here's how it should work:
You go to a website, and you save a page as an html file. Then you go into your browser and load that file as an extension. There is a simple convention where the extension asks for permissions when it attempts the action.
I mean, hey, if there isn't going to be an economic incentive to write these things, you might as well make it easy and fun for devs to write and distribute them.
Now someone just needs to write a small converter that instantly converts an existing Chrome extension for Firefox, and a script that allows people to install from the Chrome market, too, and instantly the available extensions for both browsers doubles.
It's been tried[0][1][2], but doesn't work very well. Similar to how PhoneGap tries to create a cross platform solution, it will always feel kludgy compared to developing with native APIs.
I wouldn't phrase it like that. Instead, Firefox is implementing a similar extension API, which overlaps with Chrome and Opera's APIs. What you described, "instantly converting an existing Chrome extension for Firefox" is a long ways off.
There's a lot of gaps in Mozilla's implementation right now. To do anything interesting (beyond cat gifs), you have to fall back to the old QueryInterface/ns* APIs.
> 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.
Well, Firefox users would still have an advantage. That Chrome users will never get addons that add tree-style tabs, or completely modify the UI, etc, is obvious.
But from that point on Chrome does not have many things above Firefox anymore.
For users who primarily care about extensions, but that's been true for a while. I rarely use extensions (currently I'm using, uh, Google Cast, plus the mosh Chrome app because life's too short to install software) and I care about security, and Chrome's multiprocess and sandboxed architecture has significant wins there.
When Firefox gets that, then I'd agree that at least for me, Chrome won't have many things above Firefox any more. And the new extension system is part of their plan for getting there.
> Chrome's multiprocess and sandboxed architecture has significant wins there. When Firefox gets that,
Multiprocess is currently enabled by default on desktop in the Firefox developer edition. And the release version of Firefox on Android is multiprocess and also supports extensions.
In practice, about half the extensions I use (the complex ones, like Lazarus) need a serious overhaul to work with e10s. It can't hit a stable release, there would be major breakage.
There's a difference between chrome and ff multiprocess. The sandbox model (at least on linux) in chrome is better than anything else available right now. They're pretty much the reason that kernel-level sandbox is available to us now.
Hm, both viraptor and I were downvoted without significant commentary. While I don't mind downvotes for being wrong, is anyone interested in actually claiming that we're wrong? As far as I'm aware, viraptor is completely technically accurate: the Chrome team is the reason that Linux's seccomp mode 2 is so good today. (In 2010-11 I was working on a project that assumed that the seccomp mode 2 rumors were never going to amount to anything, which was the consensus of the time.)
I don’t know enough about the sandbox model to discuss it (and I know that Google tries to have an amazing sandbox model especially because they run their browser also as OS)
But the sidebar stuff just can’t compete with the whole browser UI being effectively an XML document in the hands of an extension.
There were lots of interesting extensions doing crazy stuff with the UI at the beginning. Then they got split into some specific types, like: icon/action, content processing, extra information (typically as a side/top/bottom bar). To the point that I can't even think of one that doesn't fit in those scenarios. The extension authors were invited to comment on what's needed from the extension API to support their use case.
So are you one of the extension authors, or users? What exactly do you want to change in the UI and did you raise an issue with google or mozilla?
I am kinda both? I don’t publish extensions, but I like to write some for myself.
One case is that I can turn on/off aero glass, or add it for everything, or I can add modify the way the toolbar is unified, or I can create multiple rows of tabs, or colored tab groups.
At every moment in the past years, I used at least one of them, usually multiple such changes.
Effectively, what I want, is to be able to modify the browser UI the same way as normal XML documents. If mozilla now uses XUL, or if they use HTML, I don’t really care. What I care about is full customizability without having to recompile.
At the moment there are more gaps than API and the debugging experience is such that you have to go back and forth between Chrome (debugging any changes you made) and Firefox (looking at the global console, checking that you're within the small supported subset).
Recommending gulp is ridiculous overkill. Chrome loads files from disk directly, Firefox plans to.
... and in FF50 they'll replace gecko with blink to be on par with chrome and opera.
Seriously, I use firefox because of its addons, for which no equivalent exists for chrome, e.g. downthemall, shelve, tiddlyfox. As it looks there is little chance, these addons will continue to work with future releases of ff. So why should I continue using FF?
Any break from the XUL days are a huge plus. XUL gives you so much power but is very unsafe for the users since anything goes and that system is also very poorly documented. I sometimes had to look at the Mozilla source code to understand what was possible with the XUL based extension system. Now that we have a really great set of native dev tools inside Firefox maybe we don't need XUL anymore? I say that because maybe something like Firebug isn't possible without XUL.
> The only thing I would add is that while Mozilla is implementing most of the API that Chrome and Opera support, we’re not restricting ourselves to only that API. Where it makes sense, we will be adding new functionality and talking with other browser makers about implementing it as well.
At least focus on making it possible to do secure communications inside a browser, where for instance you may not want to trust the service provider and want to do the crypto locally. I know for instance that Nadim Kobeissi was in the past praising Chrome for its packaged apps and how they allow better security for Cryptocat than Firefox does. Make extensions such as Mailvelope be at least as secure as native apps.
Focus on stuff like that rather than enabling extensions to change how the browser looks, which likely introduce their own security vulnerabilities by design (I know many have cried about stuff like that when you announced deprecating the old add-on model).
Maybe even do that with browser components that are written in Rust. Speaking as a Chrome user and very occasional Firefox user, the more Rust you use the higher the chance you'll have to convert someone like me who cares about security and continues to choose Chrome based on that. The sooner your sandboxing architecture is on par with Chrome's the better as well.
Someone like me is not "just a niche". It's also the type of person that recommends (evangelizes even) a browser or app to every single friend he has. Don't forget that's exactly how Chrome "beat" Firefox, if I can say that - by winning over the evangelists.
> Someone like me is not "just a niche". It's also the type of person that recommends (evangelizes even) a browser or app to every single friend he has. Don't forget that's exactly how Chrome "beat" Firefox, if I can say that - by winning over the evangelists.
You're saying "don't forget that..." as if that was an established fact, but did studies confirm this? I doubt it. I don't have numbers either so that's only one feeling against another, but I think you overstate the importance of evangelists / "power users" like us. There are other factors that (to my eyes) seem much more likely to have pushed users towards Chrome, like:
- Giant physical ads in subways (in London, Paris, Amsterdam, Berlin, maybe others?).
- More ads on the web.
- Very visible hints to switch on high-volume domains like google.com and youtube.com
- Chrome having a mobile story earlier letting users sync their bookmarks & passwords across devices. By comparison, Firefox (with Firefox Sync) took some time to land on Android, and is barely arriving on iOS.
- The sorry memory-hungry, inefficient state of Firefox when Chrome was young and slim (which was fixed since then, but hurt the Firefox brand a lot).
> At least focus on making it possible to do secure communications inside a browser, where for instance you may not want to trust the service provider and want to do the crypto locally. I know for instance that Nadim Kobeissi was in the past praising Chrome for its packaged apps and how they allow better security for Cryptocat than Firefox does.
When talking about secure communication it's probably best to avoid using joke software like cryptocat as an example.
Really looking forward to some sort of interoperability between browsers plugins between Chrome and Firefox. That would be really great. However my intuition tells me thats going to be quite difficult. Not only from the technical point of view but also the perspective of developers of existing extensions... Would there be some common extension repository? What if someone takes somebody else's Chrome extension and puts it in the FF repo as his own, etc...
Wait. Isn't that the browser¹ that requires you to use an online certification process to install even your own addons/developments, unless you're on a Nightly version and change a hidden setting? skims the article
Ah yeah, they avoid the subject by using Nightly anyway due to the changing API. Note that any build other than Nightly won't let you install unsigned extensions, period. Not by changing about:config values or in any way for form I'd know about.
①: Firefox fan forever. Since they decided that no, you are not allowed to install your own build of Vimperator/TST etc. without a signature from Mozilla, I'm looking for alternatives. Unfortunately there's no real competition, it's either Chrome or FF - and FF seems to move into directions I don't like.
You can install unsigned addons in Developer Edition. I've been using Developer Edition as my primary browser for over a year. If you're the kind of power user that needs to install unsigned extensions, it's a pretty reasonable compromise...
You can always build release channel from source.
Adding a pref to release/beta for this would defeat some of the purpose of the feature - bad actors always find ways to install their shitty extensions into the browser. When the browser does signing checks before loading them, that raises the challenge significantly vs. setting some prefs and dropping a file in the right place.
Chrome has a similar extension policy. Edge probably will too. History has shown that nothing less than this will cut it. :-(
I feel that Developer Edition would solve my problem.
That said: Building FF from source takes ages. It's not something I like to do, honestly, to build/package/install a couple of JS files.
And I do think that this is a crappy idea. Okay, require signatures if you want to install something directly from the web, maybe? But if I point that thing at a .xpi file, locally, let me install that. Hide it behind a flag in about:config, but let me install that.
Saying 'ah, but someone might toggle that box for you' is weird and reminds me of Raymond Chen's 'Wrong side of the hatch' security reports. If you can do that, if your installer can mess with my about:config, why can't it f* up my whole system?
A free idea for malware distributors: Bundle your own release channel build of FF and just remove the official one, keep the user's profile. Your MSI runs elevated, I'm reasonably sure I could do that ~somewhat easily~, if you make your money with shady stuff you're bound to make this work. Tada! Every extension can be installed again, please add a couple useful and set a decent home page.
The premise is crap. The implementation is unfortunate and follows the premise.
(Again: Thanks for the DE hint. That's listed in [1] as well, I must have missed that in the past and - Nightly isn't exactly what I want to run on a daily basis. Or at least not as my main browser, a side by side install is often present on my machines)
Bad actors in this case are not exclusively malware authors. Among others, they include the developers of Skype, Java, Adobe Acrobat, most antivirus software...
EDIT: For a more specific example, at various points in the past local native apps like uPlay have been exploitable such that random websites could drive-by execute scripts or download malware. Pretty much any native app (legit or not) could potentially load an extension or install a protocol handler that lets a random website own your machine.
from the article:
>>> [...] I think it’s time to add a build script. I hear that the go-to build tool these days is gulp, so I’ll wait here while you go install that, and c’mon back when you’re done. (I needed to install Node, and then gulp twice. I’m not sure why.)
what should have been:
I hear that the go-to build tool these days is gulp, but fuck gulp and use make.
It seems like Firefox is going to become just another browser.
[1] http://www.downthemall.net/the-likely-end-of-downthemall/ [2] https://github.com/sparhami/BeQuiet/issues/2