It is basically just a little bit of javascript that runs on top of all the WebRTC code that they'd have to build anyways.

Trying to do cross-platform screensharing, for instance, can be quite a hassle, but this will allow it to be done all without any sort of plugins, or any need for TeamViewer, GotoMeeting, etc.

And as for XUL and XPCOM, they've already been moving away from it internally for years. It is horrible. Talk about bloat and security problems. And they already are needing to rewrite their APIs for things like Electrolysis, which I assume we want. So why not actually do a good job with the rewrite?

The ultimate goal is to have the UI based on web standards (browser.html). This will reduce bloat and reduce the attack surface. And the UI will only get more customizable as a result.

It feels like Mozilla has no imagination left. In the browser space I can see Chrome following its ideals and moving ahead. Recently Vivaldi has been making great strides with original thinking on what a browser should be. Oh, and Mozilla? We'll ape Chrome here and there and loose our identity and alienate our users. If I want Chrome, I would use it myself, I don't want bits and pieces of Chrome in something I've been using long before Chrome came.

Copy features and implement them like how Android and iOS copy each other; they keep their core identity intact with the changes and features adopted.

It is sad. Just look at what Microsoft has been doing to get an addon community like Firefox, and look at Mozilla throwing away all their working addons and the community to the streets.

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.

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.

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

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-...

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_....

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.

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.

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.

It's not the UI, it's the APIs behind powerful addons like Firebug that made Firefox the browser that it is. Those powerful APIs are going, going, gone.

Pretty sure it is again then the users job to create the customization features they want.

I can not often say it enough much i despise Mozilla these days.

A transition like this has two halves: adding the new (performant, maintainable, secure) APIs and deprecating the old ones. Comments like the one above jump to the bizarre conclusion that Mozilla will decide to remove of the old APIs but never add the new ones. The closest thing to an explanation for why this would happen is ... uh, something about pocket and hello?

Thus the goal is to prevent free interaction between processes or between addons and native in general (unix philosophy anyone?). Everyone has to suffer just to protect those who click on "yes, install" whenever prompted.

The result are less powerful APIs in the name of security.

Just look at addon signing. Mozilla refuses to add an off switch to that (and thus user control) because they fear that some other processes already running on the user's computer might inject unsigned addons. In my eyes this is a crazy kind of threat model that basically writes off the user's system security as a lost cause and tries to defend FF against that lost cause. It's elevating mozilla's needs over interoperability between applications.

Imagine if awk refused to run unless the parent process is bash, signed by canonical, because they deemed some other shell's argument expansion as potentially confusing to the user or something like that. Crazy, right?

What we want is the ability to modify the whole browser chrome as if it was a website, and the ability to modify every action that happens in the browser.

(For example, for tree style tabs, or a tab bar at the bottom, or stuff like redirecting some keypresses to other processes).

Vivaldi does provide these things. Vivaldi allows users to literally rewrite 100% of the actual browser with simple JS addons.

Mozilla should provide at least what Vivaldi provides.

Is there some report on the security implications of supporting XUL?

For me, even though I also do web development now and then, the web should have stayed as interactive hypermedia documents.

What matters are network protocols.

I always use native applications, when given the option.

As such, I never cared for add-ons other than dictionaries.

Blocking ads and nasty JavaScript sites? That is what the computer networking configuration is for.

If everything is behind cloudflare IPs and piped through TLS that gets more difficult.

And you'd have to defeat all the certificate-pinning/sts/etc. security just to filter some stuff.

On the other hand the browser has more knowledge about each request, e.g. whether it's actually intended to be executed as javascript or loaded as an image etc.