WebExtensions in Firefox 52 | Hacker News Reader

WebExtensions in Firefox 52

blog.mozilla.org

167 pointsAndrewDucker69 comments

Is there going to be a permissions system where I can specifically choose which set of APIs I allow to dispose to each extension?

Yes, there already is. Firefox enforces the same manifest permissions in WebExtensions as Chrome.

I assumed that the GP meant a permissions system for users, not for WebExtension developers. I don't believe there is that. It seems like it would be relatively trivial to add given the manifest permissions system is already in place though.

> I assumed that the GP meant a permissions system for users

This seems far beyond the capabilities of most users to understand. Perhaps someone can make an add-on for power users who are interested.

Android and iPhone do it, so....

For some privileges. You can say "No, don't allow photos access," but there are other permissions like internet access that you can't block.

Actually for certain classes of iOS 'apps' you can do exactly this - to enable third party iOS keyboard access you need to go into Settings and enable an extended privilege set (which includes internet access)

As well as Android and iPhone, many auth services (e.g. Facebook Connect) also offer this feature to presumably mostly non-technical users.

Also, I've not investigated but I doubt the WebExtensions API would provide access to features required to implement this as an extension (it's a much more limited extension API than previous Firefox ones)

Will I be able to keep my tree style tabs?

https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...

The moment this plugin stops working is the moment I stop upgrading. Seriously!

Chrome used to natively support tree-style tabs. Unfortunately they were removed a few years ago.

Tree Style Tabs should continue to work. It's a very popular extension. Mozilla should probably include a disclaimer about Tree Style Tabs still working with any blog post about WebExtensions. :)

Mozilla is now beta testing a prototype of native Firefox vertical tabs, though it is not as advanced as Tree Style Tabs:

https://testpilot.firefox.com/experiments/tab-center

Vivaldi has a nice Tree tab style that I constantly use, it has become second nature - we're even looking at replicating it for our enrollment software, crazy enough.

they have a bug that tracks this use case

https://bugzilla.mozilla.org/show_bug.cgi?id=1208596

and a larger in scope bug https://bugzilla.mozilla.org/show_bug.cgi?id=1315819

Firefox should concentrate on its biggest asset, ability to customize natively. For example I would like option to customize right click so when i right click term i would like to have ability to search by all search engines that i want to use not only default.Also most annoying thing in both browsers is not having ability to copy link as text not only its address.

You can copy links as text (at least in Chrome): just right-click and choose "Copy".

It's weird, I remember a similar option being there, but it's not (neither in Firefox nor Chrome)

http://imgur.com/a/ncvyt

Android still has it

It makes extra sense to have it on touch-only platforms, where selecting text is more difficult (and long-pressing a link doesn't initiate text selection).

WFM on Mac: http://i.imgur.com/67G6R1p.png

Doesn't work unless you select the text for me.

On a mid-2014 Macbook Pro, I'm having a hard time right-clicking without selecting the text using the touchpad. I think its automatic. How are you doing it?

I am using right click with a magic mouse on an early 2011-mbp. FWIW I just tried it on my touchpad without selecting anything and it doesn't show that copy option in the context menu. It is possible that it's a setting somewhere.

Yes, you can copy text of link if you select all link text but why not just by right clicking link.

Also in Firefox:

CoLT (Copy Link Text)

https://addons.mozilla.org/en-US/firefox/addon/colt/

You can customize it to copy in different syntaxes; for example you can have it copy in Wikimedia link syntax.

Use the context search extension: https://addons.mozilla.org/en-US/firefox/addon/context-searc...

If by default Firefox has multiple engines than by default i should be able to use it with right click on text.

Context Search is actually worse than default because i don't want to add one more click to access default search engine search i want to stay as it is and below that add wikipedia and WolphramAlpha engines.

Agreed. Firefox has two advantages: it's customizable, and it's not made by a major tech company. If the customization goes, then there's only one advantage left.

The thing I like about Mozilla is that it isn't Microsoft or Google. Should I be buying more tinfoil?

No, that's ok. That's one of the reasons I use ff as well.

It's a good reason IMO. MS browsers push MS services and Google does the same with Chrome. For example, I have to be logged in with my G account to download an extension for my browser. I am struggling to see the connection between the two.

Finally, google links everything together (as we saw with the resold Pixel debacle), so why would I want to increase the risk of breaking Google TOS by using their browser.

Firefox pushes Mozilla services, such as their "Sync". They've also pushed commercial services, such as "Pocket", over user objections.[1] And, of course, they were paid to make Yahoo (of all things) the default search engine.

[1] https://groups.google.com/forum/#!msg/mozilla.governance/2PY...

They don't really push Sync. Most people are unaware of it.

I disagree with many of the concerns over Pocket as they are alarmist and overblown. The Pocket code is MPLv2 (open-source) and it isn't "spyware". This is trivially verified by looking at the code.

Mozilla used to have a partnership with Google that accounted for 85% to 91% of their revenue. Mozilla needs funding to survive, and Yahoo! provides some of that funding.

It is a false equivalence to suggest that the way Microsoft or Google pushes their services is anything like Mozilla's actions. Mozilla has always pushed for an open web and strong privacy protections. Google only implemented Do Not Track after Firefox did. Mozilla just released an ad-blocking browser for iOS to go along with their ad-blocking add-on. Comments like these only push that false equivalence.

Mozilla's Firefox Sync server code is open source and even packaged so you can run your own Firefox Sync server, if you are concerned about privacy or Mozilla no longer supporting the service:

https://github.com/mozilla-services/syncserver

True. They are not without sin. I still trust them more than others at this point.

I dont think you deserve Downvotes because that's a perfectly reasonable point to discuss.

>For example, I have to be logged in with my G account to download an extension for my browser.

What? I can download chrome extensions just fine when logged out.

Nope, that's a big reason I stick with them.

The post indicates that 52 was released this week, but Developer Edition still shows the latest update is 51.0a2 for me. Anyone else?

Same here.

This is basically "we have to be compatible with the guys with the bigger market share". Unclear why. Nobody installs add-ons on Chrome. I have the same add-on for Firefox and Chrome, and it has 100x the installs on Firefox that it does on Chrome.

The current Firefox extension platform is a mess. There are XUL add-ons, Jetpack add-ons, and SDK add-ons, nothing is fully compatible with E10s, and to say the security features are lacking would be an understatement.

The Chrome platform on the other hand was designed to be multi-process from the ground up, has some solid security research behind it (like actual academic studies), and generally just makes sense. The Chrome extension system (or something very similar to it) is also already supported in a bunch of other browsers, so why would Mozilla not use it in theirs?

E: typo

uBlock Origin, as a random popular example, has 2,231,919 users on Firefox and 6,483,302 users on Chrome. So Chrome has almost 3x as many uBlock Origin installs, though Chrome has about 5x more users than Firefox. From this one data point, it would seem that people using Firefox use more extensions, which interesting.

https://addons.mozilla.org/en-US/firefox/addon/ublock-origin...

https://chrome.google.com/webstore/detail/ublock-origin/cjpa...

Might be a bad example, as Mozilla is promoting uBlock Origin right on the first page in the Add-ons section. It takes just three clicks to go from a newly installed Firefox to having uBlock Origin installed.

Then again, though, they only just recently switched that over from previously promoting AdBlock Plus, so I don't know how much of an increase that has caused in that time.

They needed to revamp the plugin architecture in order to support multithreading. The current FF extension API relies on the fact that the browser UI and the Web content share the same OS thread.

Google Chrome was built with multithreading in mind from the ground up (well, even multiple processes), and its extension API was designed around that architecture.

I think Mozilla made the right choice by picking and extending an existing API that has seen a lot of real world code written against it, rather than inventing a new, incompatible one.

They needed to revamp the plugin architecture in order to support multithreading. The current FF extension API relies on the fact that the browser UI and the Web content share the same OS thread.

No, it doesn't. The long-obsolete XUL API did, but the current Jetpack API does not. There's a per-addon task and a per-page task, which communicate via message passing.

Oh my bad, I mixed things up...

Jetpack/SDK still isn't fully E10s compatible, see https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Multi...

Only if you use low-level APIs from the "privileged module" list.[1] The main high-level Jetpack APIs are multiprocess-compatible.

[1] https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_AP...

It's a nice side-effect to be compatible with Chrome-extensions, so that even if Chrome continues eating up the browser marketshare that there will still be extensions available on Firefox, but the main-motivation was simply that Firefox needed a proper extension API and then why design an API from scratch, if there already is one that does everything you need.

Cool work, and When do WebComponents become enabled by default, does anyone know?

Doesn't look like they are really actively working on it:

https://bugzilla.mozilla.org/show_bug.cgi?id=889230

https://bugzilla.mozilla.org/show_bug.cgi?id=1205323

Which is weird because FF devs are active in spec discussion for web components. Maybe they are working on some lower-level infrastructure stuff before they can tackle these, I'm not sure.

If you look at https://bugzilla.mozilla.org/show_bug.cgi?id=1274159 there's recent activity on Custom Elements.

Firefox already has most of the pieces for web components because XBL (an XML thingy for building UI widgets that is basically WebComponents but older). I suspect it's just blocked on deciding when the spec is ready for implementation in Firefox.

Most web component websites suffer badly on Firefox, due to polyfills. I m still hopeful.

So, is this the version of Firefox that kills all existing add-ons?

no, its just an update on its current progress

Haven't they been working with add-on makers to port things over?

Yes.

* https://blog.mozilla.org/addons/2016/08/02/multi-process-fir...

* https://developer.mozilla.org/Add-ons/Working_with_multiproc...

So, when will we be able to use WebExtensions to modify the main UI’s scripts and DOM?

I want to add tab previews with screenshots on hover (as in vivaldi), I want to use custom history (and completely change the way the omnibar works by searching through that custom history server with fulltext indexing of all visited webpages).

When can we expect that (which is possible with existing extensions) to land in WebExtensions?

Not any time soon. They're aiming for maximum compatibility with Chrome extensions, and Chrome doesn't have anything like that, so I wouldn't expect it to be a priority in Firefox either.

This seems like literally the stupidest thing they could prioritize.

The new multi-process architecture is fundamentally incompatible with many of their old extension APIs. The new multi-process architecture is one of their priorities (they're the last popular browser to get a multi-process architecture -- even IE has had this forever -- and it will solve many of their performance issues), and so another priority is implementing new APIs for extensions to use.

I seem to remember them saying that they're interested in adding functionality required by the current addons though. Probably less of a priority than perfect compatibility with Chrome though.

IIRC they're also aiming for most existing extensions to still work (and working with extension authors on this). The extensions will require updating, but the base functionality won't be lost from the spin so an extension that used to work can be rewritten to still work.

The Chrome API is just a base. There's a lot of misinformation about this switch floating around. The intention is to not break existing addons.

They have compatibility layers available. You don't have to wait for WebExtensions to add those features, just do it with the old APIs and switch when ready.

Yes, that works for now.

But if I'll implement these things, I'll want to do them using the new APIs in the first place.

So I'm waiting for the new APIs to come.

Please stop spreading FUD about the switch. The plan is not to kill all extensions.

Why do browser makers keep implementing new ways for companies to spy on end users? I had expected better of Mozilla.

The response to the web of trust shit show should have been to neuter add ons.

Mozilla has been gradually restricting what add-ons can do in Firefox precisely because of problems with malware. This is another step in that process.

Reply on news.ycombinator.com