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