top | item 16242336

Extensions in Firefox 59

496 points| ac29 | 8 years ago |blog.mozilla.org

236 comments

order
[+] npongratz|8 years ago|reply
I find this pretty exciting for (hopefully; someday) wider adoption of alternative protocols:

Starting with Firefox 59, several protocols that support decentralized architectures are available for use by extensions. The white-listed protocols are:

+ Dat Project (dat://)

+ IPFS (dweb:// ipfs:// ipns://)

+ Secure Scuttlebutt (ssb://)

[+] soapdog|8 years ago|reply
Hey! I made that patch! :-D

so basically the explanation is simple. There is a whitelist of protocols you can have your WebExtension take over.

If the protocol you want to control is not on that whitelist such as an hypothetical "catgifs:" protocol, you need to prefix it like: "web+catgifs" or "ext+catgifs" depending if it will be used from the Add-on or by redirection to another Web page. This makes it inconvenient to use with lots of decentralization protocols because in many other clients we are already using urls such as "ssb:" and "dat:" (eg, check out beaker browser). In essence this allows us to implement many new cool decentralization features as add-ons now that we can take over protocols, so, you could be in Firefox browsing the normal web and suddenly see a "dat:" link, normally you'd need to switch clients to a dat enabled app, now, you can have an add-on display that content in the current user-agent you're using.

Still, there is another feature that we need before we can start really implementing decentralization protocols as pure WebExtensions, we need both TCP and UDP APIs like we had in Firefox OS (as an example, Scuttlebutt uses UDP to find peers in LAN and its own muxrpc TCP protocol to exchange data, DAT also uses UDP/TCP instead of HTTP).

I have been building little experiments in Firefox for interfacing with Scuttlebutt which can be seen at:

https://viewer.scuttlebot.io/%25csKtp9VmxTjJoKy17O7GA6%2F3S8...

https://viewer.scuttlebot.io/%25uBev5w8m8iZGVbQDo9fpr%2BCXLB...

I hope to start a conversation in the add-ons list about TCP and UDP APIs for WebExtensions soon :-)

[+] kodablah|8 years ago|reply
Why does it require a whitelist? If I make my own, do I have to contact Mozilla or is the user prompted when first access is attempted?
[+] fiatjaf|8 years ago|reply
Honest question: who's using ssb://?
[+] kibwen|8 years ago|reply
Happy to see that Mozilla was serious about their intentions to extend the WebExtensions API in post-57 Firefox. I'm also happily surprised at the section about user notification of extension overrides; having a nice UI for this sort of thing is a difficult yet worthwhile problem (and I'm also a big fan of the new Preferences tab in general, it works far better than the old popup window). Hopefully some of this will make it in time for the next ESR so that people who are still on Firefox 52 ESR due to unsupported extensions will have the option to upgrade (though I don't see anything that will satisfy the vimperator users, I'm encouraged by the new mouse gesture APIs). Kudos to Mozilla for conducting this process with an eye towards keeping the security threat of addons reasonably manageable, even if the overall process is slower than we'd otherwise like.
[+] wkalt|8 years ago|reply
I discovered tridactyl (https://addons.mozilla.org/en-US/firefox/addon/tridactyl-vim...) a couple months ago. While it doesn't have total parity with vimperator, it's much closer than vimium and vimFX, and unlike for those projects, parity seems to be the actual goal.

YMMV, but as someone who was stuck on ESR for a long time for this reason I am now completely satisfied on 57.

[+] JohnTHaller|8 years ago|reply
It's funny that vimperator is mentioned every single time Firefox extensions are brought up on HN even though it only has about 11,000 users out of the hundreds of millions that use Firefox.
[+] sundarurfriend|8 years ago|reply
> though I don't see anything that will satisfy the vimperator users, I'm encouraged by the new mouse gesture APIs

Yep, me too. I switched to Waterfox for the time being because of how important FireGestures is to me. If full-fledged mouse gestures extensions become available in Fx again, that would be a big step towards making the new Firefox usable for me.

Since you mentioned vimperator, another major issue for me is the lack of a VimFx style extension - that one is much simpler than vimperator or pentadactyl, and has other new attempts at alternatives, but 'Saka keys' is the one that seems to come closest (and makes this less of an issue than the mouse gestures one) and that's still kinda buggy and years behind VimFx in terms of features.

I would have missed Tab groups though it's not that big of a deal to me, but I'm glad we'd have that feature again. And another minor issue in that league is the lack of a good Speed Dial extension with a decent UI and set of features (which none of the "replacements" had last time I tried them out).

[+] cpeterso|8 years ago|reply
Firefox 60 will be the next ESR version, so all of the Firefox 59 extension APIs described in this blog post should be available.
[+] nathcd|8 years ago|reply
I have a tangential question for anyone who might know more about tab stuff than me.

Awhile ago, I looked into making Firefox not do any tab management. Basically, always have one tab per window, middle click always opens a new window, normal click always opens a page in the current tab. (I'd like to do tab management with my window manager instead of browser so I can have a consistent tabbing interface across all of my applications.)

The few results I found googling around seemed to be mostly along the lines of "change these 14 prefs in about:preferences, install this addon to stop target:_blank, add these userstyles to hide the tabbar, don't open any internal FF pages, and check back with every new browser version".

Am I missing something that would make this easier, or is this really a thing that's just not really feasible? I can certainly understand that it's not a priority since almost no one needs to disable tabbing, but it also doesn't seem like that farfetched of a use case, nor would I imagine it would require much work to support.

[+] geekamongus|8 years ago|reply
I went all in with 57 (the first 'Quantum' release) after having been a Chrome user for quite a while. I really haven't missed Chrome at all since I made the move, and in fact, am continually impressed by the little things in Firefox that I keep discovering. Not to mention the speed.

These changes look like they will eventually make things better, especially for extension developers and those of us who get to reap their benefits.

Keep up the good work, Mozilla.

[+] neuland|8 years ago|reply
> ... one of the most requested features has been the ability to hide tabs with the WebExtensions API. It was a key element of some very popular legacy add-ons ...

It's weird that they are not mentioning Tree Style Tabs by name. But, at least they're listening the the user requests.

I don't use the plugin myself, but I heard that one of the gripes of the new WebExtensions version is that it still shows the normal horizontal tabs.

[+] gogoengie|8 years ago|reply
They are referring to hiding individual tabs, not hiding the horizontal tab bar.

The legacy extension they are referring to is Tab Groups [0]. It allowed you to separate the tabs of a single session into groups. Selecting the active group would hide the other tabs.

[0] https://addons.mozilla.org/en-US/firefox/addon/tab-groups-pa...

[+] wlesieutre|8 years ago|reply
Seems reasonable to not mention a specific one by name so as not to play favorites going forward if someone else wants to make a competitor. Or maybe a Grid Style Tabs, or who knows what.

I imagine it's the same tone they use for discussion of adblocker related features, "we need this for content blocking addons" rather than "we need this to support uBlock Origin."

Hiding the top tabs can be done in current versions but you have to go digging through settings folders and set up a css file with some rules. There's also a built-in header on the sidebar than can be hidden by similar means. Hopefully they'll also let us hide that header (it lets you switch to other sidebar views like Bookmarks and History that I don't want to use in the sidebar) so I can avoid the css setup in the future.

https://i.imgur.com/mMlrU1n.png

[+] kej|8 years ago|reply
>one of the gripes of the new WebExtensions version is that it still shows the normal horizontal tabs.

In case anyone is in this position, it's relatively easy to hide them with a userChrome.css file: https://superuser.com/a/1261661

It would be nice if the extension or an easy to find setting could do it, though.

[+] scoates|8 years ago|reply
FWIW, I have this in my userChrome.css to fix that horizontal tabs annoyance: `#TabsToolbar{ visibility: collapse !important;}`. Not ideal, but a workaround I can forget about most of the time.
[+] scrollaway|8 years ago|reply
Anyone working on this reading the thread? Can we ever expect an extension that will allow the far better tab management that Chrome has? Namely: Being able to scroll between tabs with the scroll wheel, and being able to select multiple tabs with shift/ctrl to drag them/merge them/close them/etc.

It's crazy to me that Firefox's original selling point was tab management, and today Chrome's is so much better.

[+] rocky1138|8 years ago|reply
As a technical user who values choice and customisability, I am totally fine with their choice of disabling tab hiding until you flip a bit in the configs. It's the best of both worlds: customisability for power users and security for regular folks.
[+] dbdr|8 years ago|reply
> pageActions can now be shown and/or hidden automatically for specific pages via pattern matching using the “hide_matches” and “show_matches” manifest properties. This is a nice performance win for users.

When writing an extension that shows a page action only for certain domains/URLs, this allows to replace about 15 lines of javascript code with a single line in manifest.json. Nice!

[+] shmerl|8 years ago|reply
Mozilla should fix no exit confirmation for Ctrl+Q. It's just too easy to close the browser this way, and extensions that offered this feature aren't working anymore.

It's really a problem in general, there is no way to make an extension that customizes browser behavior itself (rather than page behavior), since WebExtensions can't do that.

[+] virtualwhys|8 years ago|reply
Was hoping to see Web SQL make its way back into Firefox.

Yes, it's been deprecated for years, but that hasn't stopped the browser makers with majority of market share (Google > Chrome, Apple > Safari) from continuing to ship it along with the strictly worse alternative (IndexedDb).

Now that pretty much every language compiles to Javascript it's a shame to lose SQL functionality on the client. Shared model, shared validation, shared SQL layer, etc. -- it could all be a unified whole, but no, now one has to wait for sqlite-lite to be built on top of IndexedDb; that or throw everything out and go NoSQL on client and server.

[+] jgj|8 years ago|reply
> but no, now one has to wait for sqlite-lite to be built on top of IndexedDb

not exactly sqlite-lite, but it's sqlish and it's build on top of IDB: https://github.com/google/lovefield

[+] pcwalton|8 years ago|reply
Web SQL was never in Firefox.

The problem with Web SQL was that the spec was effectively just "whatever SQLite does". That isn't good enough for the Web. Imagine if the GIF specification had been "whatever GIFLIB does". Libraries like Lovefield can be built way faster than specifications can be written.

[+] CorpusCalcium|8 years ago|reply
What practical benefit would that really have over just using your choice of SQL engine with wasm, though?
[+] fiatjaf|8 years ago|reply
Why would you want SQL on the browser? You cannot sync it to any SQL backend. Are you shipping pure client-side apps with complex data structures?
[+] neil_macintyre|8 years ago|reply
Is IndexDB slow at querying a database or is it just a pain to implement?
[+] cirowrc|8 years ago|reply
This is very cool:

> Extensions can now override the proxy settings in the browser which has been another highly requested feature

I see that there's an opportunity here to improve the experience of using SOCKS in the browser. Pretty cool.

[+] fro0116|8 years ago|reply
Not really related to extensions, but one thing I've been curious of for a while now: Does the Firefox team have any plans to implement something like Chrome's expensive background timers throttling feature?

https://blog.chromium.org/2017/03/reducing-power-consumption...

It seems more and more relevant these days with the advent of cryptocurrency miners.

[+] paul7986|8 years ago|reply
Does this mean tabmix plus is now once again compatible? An add on I used for ten years.
[+] lillesvin|8 years ago|reply
I recently tried to switch back to Firefox from Chrome because I was missing how Vimperator was able to hide all of the UI and just give me a small statusbar at the bottom like in Vim. However, I found that's no longer possible with WebExtensions, so now I'm wondering if anyone has any suggestions if I want a browser with absolutely minimal UI and Vim controls?

Seems like we're getting closer with this version though. I might just have to be patient.

[+] hendersoon|8 years ago|reply
Minor note, the mouse gesture config flag they speak about in this article, allowing mouse gestures to work on Linux and MacOS, was actually added in Firefox v58.
[+] joveian|8 years ago|reply
I hope FavTab will be able to work again. That is the one thing that has really messed up my usage of Firefox (I'm using AutoPinTab to pin everything as a replacement, but it causes flashing when it overlaps the favicon bookmarks I have to the right of the tabs and makes Ctrl-w not work).
[+] joemccall86|8 years ago|reply
> To better support mouse gestures, browserSettings.contextMenuShowEvent() has been added in this version. This new API can be set to “mouseup” or “mousedown” by extensions to determine when context menus should be shown.

Looking forward to using FireGestures in Linux again.

[+] contravariant|8 years ago|reply
Now if only they could come up with something that means I don't have to wait for a page to load before regaining control with custom hotkeys / gestures.
[+] seanwilson|8 years ago|reply
If you have an existing Chrome extension that relies on just the WebRequest API, how much effort is it to port to Firefox? Do things generally work without significant modifications? Are there lots of gotchas and small differences?