Let’s Write a Firefox Web Extension
hacks.mozilla.org
hacks.mozilla.org
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
Out of curiosity, if there was a Firefox App Store, how much would you pay for Tree Style Tabs?
Probably a few bucks. TST is pretty fundamental to my Firefox workflow.
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.
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.
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.
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.
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.
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.
Mozilla already know (for a large part) what APIs they need; they keep stats on the extensions: https://addons.mozilla.org/en-GB/firefox/extensions/?sort=us...
So at least enough to implement the top 50 ? Preferably the top 500 :)
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...
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.
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.
But from that point on Chrome does not have many things above Firefox anymore.
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.
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.
Also while I'm here, a certain [dead]-and-proud account linked this bug which is somewhat relevant (but only somewhat, in my eyes): https://code.google.com/p/chromium/issues/detail?id=477424
But the sidebar stuff just can’t compete with the whole browser UI being effectively an XML document in the hands of an extension.
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?
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.
browser.html is one step in the right direction.
[0] http://kangoextensions.com/
So, doing this should be easy.
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.
See http://www.downthemall.net/the-likely-end-of-downthemall/
> 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.
[0] https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...
Recommending gulp is ridiculous overkill. Chrome loads files from disk directly, Firefox plans to.
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?
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.
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).
When talking about secure communication it's probably best to avoid using joke software like cryptocat as an example.
①: 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 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. :-(
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)
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.
what should have been:
I hear that the go-to build tool these days is gulp, but fuck gulp and use make.