Hacker News Reader

Comment by callahad | Hacker News Reader

> Extensions like Vimperator/Pentadactyl, that makes deep changes to the way Firefox operate would not be possible under the new system.

You're mistaken. Vimperator is explicitly on our list of add-on functionality to support at https://wiki.mozilla.org/WebExtensions#Additional_APIs, and it has been there since the very early days of the WebExtensions project.

Will WebExtensions v1 be ready to handle Vimperator? Absolutely not. But we'll almost assuredly get there before we remove the existing APIs that those add-ons rely on.

View on HN

That's great to hear. I can't live without Vimperator, and it's really good to see that there's a decent plan in place to keep it (or close substitute) alive.

I may be wrong on the specific case of Pentadactyl. But as a user I am happy to be wrong in this case. I love that extension

However, there are many extensions that won't be possible in the new extension environment and they will die a silent death as they don't have cheerleaders who can force Mozilla to accommodate them in the new webextension plans; I know one or two such extensions myself (don't use them personally, so I may be wrong, may be not). This forced euthanasia of extensions make FF ecosystem poorer, and FF just another Chrome wannabe.

The point is, Mozilla should show the traits of leader; criticism still has merit whether Vimperator work or not.

> die a silent death as they don't have cheerleaders [...] I know one or two such extensions myself

Then name them! It is literally my job to help developers interface with and be heard within Mozilla.

Don't you understand that the need to speak before our mozilla king to be heard is already a problem, no matter how benevolent the king is we still become supplicants before him. And not everyone will be willing to ask, so things die silently.

And then there also is the issue that mozilla has limited resources. So even if you wanted to help you can't help everyone.

This does not exist in the old extension ecosystem or in regular software development. You don't have to beg anyone to please spend time a particular usecase.

It may be painful to get things working yourself, but at least it's an option you have.

Here's an example of users helping each other without needing to petition for support from orbital HQ: http://stackoverflow.com/questions/36927096/firefox-command-...

Will the WebExtensions API be powerful enough to write a "browser firewall"? Essentially give users automatic/manual control over about every process run by the browser.

I don't think we're exposing native process semantics to WebExtensions, but the webRequest API can intercept and modify any request initiated by web content.

If this use case is important to you, please file a bug explaining your needs and/or fill out the survey at https://wiki.mozilla.org/Add-ons/Contribute#Improve_add-ons_....

> on our list of add-on functionality to support

But that's the problem. Things not "on your list" will simply not be possible. Right now an addon - with enough grease - can do anything that C code in the browser itself could.

In other words, the new API will cause a non-zero amount of existing addon features to cease existing and currently-possible future addons from never coming into existence.

> Right now an addon - with enough grease - can do anything that C code in the browser itself could.

Yes, and that is a bug that has blocked enormous improvements in Firefox's speed, stability, security, and fundamental architecture for years. This is going to be a painful transition, but I'm confident that the cure is better than the disease, and that the long-term cost to extensibility will be less than predicted.

Maybe I'm wrong, but this feels similar to how the Web itself lost many capabilities and existing projects with the move away from native plugins. We no longer have Java or Flash to circumvent limitations in the Web platform, but in my experience, the Web managed to sufficiently narrow that gap so that I don't miss them at all. I certainly wouldn't turn back the clock, given the chance.

The web only has become less interoperable with native operating system facilities, not more.

You can't even grant a website access to a specific directory. like "myimages/flickr.com" or whatever.

Stdio. It's so fundamental. And the web can't do it. After so many years. Addons can do that. But not webextensions.

So what you call a bug that needs to be removed I call basic interoperability.

Will you get all the features Vivaldi has (like customizing everything via settings and addons) before you remove XUL?

If all you intend to provide in that regard is "Better keyboard shortcut support". Then no, Vimperator functionality will not be supported.

Reply on news.ycombinator.com