I've been working on a very simple WebExtension [1] lately, mostly to experiment with the API and familiarize myself with extensions development in general, and the reload functionality and compatibility improvements are definitely very welcome additions.
I would also prefer to have the extensions debugging controls available in the about:addons page as opposed to in a separate about:debugging page, similar to how Chrome's chrome://extensions/ page is organized.
Also, I'm curious if there are any plans to implement something like Chrome's event pages [2] as an alternative to having a background page running constantly for extensions that don't require a long-running process?
The topic's been discussed to death, but I'm really disappointed that Firefox extensions have gone the direction of Chrome's. Sure, it's nice to have compatibility, but at the cost of Firefox's more powerful extensions? No thank you.
> but at the cost of Firefox's more powerful extensions?
What do you believe you'll be missing? Add-on authors say the new API will meet their needs. Giorgio Maone, the author of NoScript, says he's satisfied with the direction of the development of the new API: https://hackademix.net/2016/03/09/webrequest-where-were-wher...
If you develop some add-on that needs features the new API doesn't currently provide then I'd say the best thing to do is to get involved with the development and get those features added.
Quite a few add-on authors say the direct opposite, that an WebExtensions only future will kill their add-ons and that there is no way mozilla will be able to provide enough APIs to stop that from happening.
PS: It goes without saying that Giorgio and NoScript due to their popularity and because Giorgio is very well networked within mozilla get a lot of special treatment an add-on that has only a couple of hundred or thousand users will not. This isn't a bad thing, for NoScript at least, but does not help other add-on developers.
> This isn't a bad thing, for NoScript at least, but does not help other add-on developers.
You should read Giorgio's blog post. The API features NoScript needs also help FlashGot, Ghostery, RequestPolicy Continued, ad blockers, and similar add-ons.
Both multifox and Chris Finke's blog posts are not saying their add-ons aren't possible with the new API, just that they don't want to rewrite them for the new API. Chris Finke is looking for new maintainers for his add-ons. Why don't you become the new maintainer for, say, RSS Ticker (or another of his add-ons) and port it to the new API? See RSS Ticker's page: http://www.chrisfinke.com/addons/rss-ticker/
Yes, try to spin it all you like, it does not change the facts, which are:
* NoScript is getting preferential treatment. That this also has positive outcomes for a handful other (block something) add-ons does not change this or address the situation at large. Add-ons on Firefox are so much more than just fiddling with some web requests.
* Not all add-on authors are happy with WebExtensions or think they will be able to "port" their add-ons, if not for lack of APIs then for time constraints.
* Thousands of add-ons will be broken. While many can be "ported" as you put it (which is usually an entire rewrite), it is far from clear how many will be actually rewritten by the original developers or somebody else, and how many will be just abandoned or cannot be ported at all.
The transition to WebExtensions is absolutely necessary though, from both a security standpoint and developer friendliness standpoint.
The current Firefox extension model is simply too powerful. The API surface (and thus attack surface) is humongous, and extensions can literally change and replace any part of the browser's native UI with little restrictions, leaving the browser open to all sorts of phishing attacks from extensions and making it a nightmare to ensure extensions compatibility because any change whatsoever to the UI can break something. This is a large part of the reason why Firefox extensions still require manual audits while Chrome extensions don't. The status quo is not simply sustainable for Firefox, especially when considering how little resources Mozilla has to spare compared to tech giants like Google.
In addition, XUL is an archaic technology that should eventually be replaced by proper web standards in order to leverage the skills and knowledge of the entire web development community like Chrome has done. Quite a few of my web developer colleagues maintain Chrome extensions in their spare time, and when I ask why they don't offer a Firefox version as well, 9 out of 10 times the answer boils down to not wanting to work with XUL. WebExtensions will alleviate not only the problems with XUL itself, but will also offer great compatibility for building extensions that work across browsers, making the lives of extension developers even better, which will only help make the extension ecosystem even more vibrant than it is today.
The people at Mozilla have been working with extension developers however they can to enable them to port extensions to WebExtensions. If some extension developers simply choose to abandon their extensions instead of working with Mozilla to port them, that's their decision to make, but I feel it's rather unfair to blame Mozilla for this.
I use Firefox as my main browser mostly for the extensions, and needless to say, I'm a huge fan of Firefox's current ecosystem of extensions myself. The potential of losing some of my favorite extensions does suck a lot, so I understand where a lot of the frustration is coming from. However, I'm also extremely optimistic about WebExtensions and the future of the budding cross-browser extension ecosystem, and have no doubt that even if some of my current favorites end up being abandoned, a new wave of great extensions will come to replace them in due time.
Just to clarify, I'm not all all against WebExtensions.
You made some good points in particular regarding developer mindshare. Yes, (mostly) cross-browser extensions are the way to go, and it's rather unfortunate that the a lot earlier JetPack/Add-on SDK failed in that regard, among other things.
There is no reason for WebExtensions not to exist, and plenty good reasons for them to exist. But that has nothing much to do with the question of whether WebExtensions should be the only supported extension type in Firefox.
I'm not convinced about the other points you make, though. Extensions right now are extremely powerful indeed and there are certainly security considerations to be taken into account. But Chrome extensions have most of the same issues: There have been tons of extensions ex-filtrating sensitive user data or doing other shenanigans in the Chrome Store, mostly because the Chrome review model is "automatic review everything after some piece of software tries to check some basic things and ask questions later". You might get a smaller attack surface with a more limited API, but to make sure users don't install malware you'll still need a human to catch malicious people trying to game the system.
Given that mozilla plans additional/extended APIs for a lot of things that might be quite powerful in their own right, manual reviews might be still a necessity after all for lots of extensions.
XUL might be archaic as you call it but XUL is not even the point. If Firefox transitioned away from browser.xul to browser.html today, extensions would break but most of the porting would involve replacing <toolbarbutton /> with <button class="toobarbutton"/> or something like that. Most of the "native" XUL can be replaced by web components without anybody noticing, and in fact parts of XUL is already html underneath even today.
The power of current Firefox extensions comes from XUL having a DOM (just like HTML, just with other element names) combined with access to the low(er) level stuff, mainly the browser.xul javascript scope (just like a browser.html javascript scope) and XPCOM scripting (and a browser.html will still need XPCOM or equivalent access).
WebExtensions take away that power in favor of a more well-defined but thusly more constrained and limited API. I think the pro of having virtually unlimited extendability as demonstrated by tons of great and creative extensions outweigh the cons of larger attack surface and higher maintenance costs for both mozilla and add-on developers.
Add-on developers wanting "easy" or a single cross-browser codebase would be still free to use WebExtensions, which would also give mozilla a break, while the more/most powerful add-ons could still hack deeply into the browser.
I don't blame mozilla for developers abandoning their add-ons because they lack the resources, motivation or APIs to do a port (or any combination thereof), however developers abandoning their add-ons is still a reality and should not be disregarded just because mozilla might try their best to keep the fallout somewhat low.
mozilla, however, made a decision to break existing add-on en masse, and that decision and the reasons and effects should be allowed to be critically inspected.
> I think the pro of having virtually unlimited extendability as demonstrated by tons of great and creative extensions outweigh the cons of larger attack surface and higher maintenance costs for both mozilla and add-on developers.
It looks like our disagreement boils down to this single tradeoff. Firefox's virtually unlimited extensibility definitely resulted in some amazing extensions that wouldn't have been possible with any less flexible system. However, I don't believe the security and maintenance costs imposed by such a system can be justified in the case of a web browser used by millions of people where security and iteration speed is paramount.
Those looking to experiment without limits can still fork the browser codebase itself to build proof of concepts that way. If the proof of concept is compelling and gains enough traction, it would then become much easier to propose the necessary extensions to the WebExtensions spec and have them accepted and built. There is definitely a lot of friction to this process, but the alternative of maintaining Firefox's status quo with respect to extensions is just not going to be viable, in my opinion.
There is no "spin". You're seeing grand conspiracies where there simply aren't any. If you're not going to contribute to add-on or API development then relax and don't worry about it. The prophecies of doom will go unfulfilled and the world will keep on turning (or spinning if you like).
The spin I was referring to is you trying your hardest in all the threads to make it look like everything is great and peachy in the add-on space, including broadly stamping differing opinions as FUD.
While I contend the actual picture is a lot more complicated.
Because I have no interest in RSS Ticker or any of Chris Finke's add-ons. I don't use them and it doesn't matter to me if they're maintained or not. If it matters to you, then the clear way forward is to get involved.
I was sad to see that -- Tree Style Tabs is the killer Firefox feature for me. Maybe if Firefox can show the sidebar API works it'll get another hearing with Chrome as well.
The second link in the article goes to the WebExtensions overview page, which mentions "Tree Style Tabs" by name as something that new APIs need to be build for. https://wiki.mozilla.org/WebExtensions
The old XUL (non-restartless/jetpack) extensions are currently about the only way I know to actually hack on the browser's core without having to patch omni.ja and having to set disable_xul_cache, which is quite a terrible way to extend the browser.
If even those are removed or blocked, there won't ever be a way (ok, a way without explicit Mozilla's blessing) to implement custom password stores (think OS X Keychain, KDE KWallet or GNOME Keyring), or a custom sync engine, or tree-style tabs.
And with WebExtensions I can't find (maybe that's me, though!) an equivalent of preferences/service Add-on SDK API.
I had always assumed chrome.storage.sync API is all about using sync rather than implementing it. I.e. extension acts as a client, rather than provider. I mean, that API already provides a localStorage-like objects that one can use to put and get data. Technically, one can listen for events and have a custom backend this way, from my understanding, this is extension-local, and not browser-wide interception.
Now I wonder - maybe I got it all wrong? Does it actually allow to completely override built-in Firefox Sync (and either ditch Firefox Accounts requirement for Sync engine to start[1], or override those as well) and replace those parts with a custom implementation?
Say, I don't want any Mozilla nonsense, and want Firefox to sync with a simple WebDAV storage (rather than their proprietary protocol), and do so authenticated with a sane(r) X.509 client cert rather than an ugly mess of BrowserID, HAWK and OAuth2. Is that possible?
____
[1] This part is probably easy through messing with browser's preferences (the ones in about:config), but I'm not sure there's a WebExtensions API for this. Have looked for it and haven't found anything.
I'd say it's FUD from 8 months ago. In that blog post they say that NoScript and Tree Style Tabs will no longer be possible with the new API. Meanwhile the author of NoScript says the new API works for him and Mozilla is making sure the new API provides the features that add-ons like Tree Style Tabs need. No need for fear, uncertainty, or doubt.
what is needed for a DTA-like, is some way to make arbitrary connections with arbitrary headers (which I would be surprised if it isn't provided), some way to write to a file with some reasonable control over how that file is written (writing and seeking, not the most needed thing, but would obviously be preferred), and some way to display UI (a html panel)
This might be harder or easier to implement than DTA is, but there probably won't be a direct port of DTA ever due to how tightly coupled it is with firefox
Old extensions have access to js-ctypes. Which means it can do anything libc/any native library does. Spawning processes, filesystem access, interacting talking to native applications (no, connectNative definitely does not count, because it requires opt-in and special support and thus does not provide interoperability)
They can also freely manipulate the browser UI.
Chrome extensions can't do either of those.
Mozilla has some future plans on providing extensibility, but as long as those are just plans without any schedule or implementation i'll remain pessimistic that it'll still result in a reduction of available feature space.
They also "updated" the search box, beside extensions the main reason why I still prefer it over Chrome. Firefox is slowly but surely becoming unbearable. It's a real tragedy that its market share has suffered as much as it has but Chrome users aren't coming back. If they keep this Chrome-ization their remaining users just won't see any reason to choose Firefox over Chrome and they will leave.
Yeah I agree. Firefox is slowly becoming a Chrome clone. It took them a long while to migrate everything to follow the Chrome lead (release strategy, update strategy, multiprocess architecture, sandboxing, extension API, HTML UI, etc.) but I wonder what's the benefit of having two identical browsers. Yes the HTML engine is different but then so what, I don't think end users are ever going to switch because of HTML engines.
I like Chrome's UI a lot so I don't mind Firefox becoming that. However, god damn it I just want a good browser. One I don't have to restart on a regular basis. One that doesn't become sluggish after a day of usage, or 20 tabs open.
Firefox right now is an overall sub-par experience. Of the two, it's the only one that I've seen actually crash (Chrome has individual tab crashes). The scrollbars aren't stylable and it is a lot slower.
And then Chrome has its own issues as well. Its "Restore tabs" dialog is too easy to click away (firefox's is a lot better) and it just loses the tabs. Not to mention when there's a lot of tabs to restore, it loads everything at once instead of doing lazy loading like Firefox. And Chrome still doesn't have autoscroll... I use an extension for it, but it can't touch the chrome:// pages...
These are all extremely long standing issues, it's incredible they haven't been fixed. Fat good that competition between Mozilla and Google is doing.
Does there need to be a difference? Having two independent "rival" implementations of every feature is useful for the health of the web development ecosystem. The two apps could just be completely interchangeable from a user's perspective—a single site giving users one or the other for download at random—and that would still be true.
Still, an extension for a popular message board that was being developed was about to get me to switch to Chrome, but turns out that with almost no modifications it works great in Firefox nightly too! If not for that there's no way anyone was going to bother to port it.
Yeah it's honestly pretty disgusting. Mozilla's strong add-on system has been one of their largest advertisable features for /years/. Just because a bunch of people have switched to inferior webkit/blink based browsers doesn't necessarily mean that the opposition's technology is superior. If I were the head of Mozilla, I'd get rid of everyone who has suggested: removing complete themes, removing the XUL/XPCOM add-ons and SDK, cutting off support for thunderbird/SeaMonkey/etc. Servo is an interesting browser project, but it's also a /separate/ project. They need to stop focusing on stupid fluff like pocket/hello/etc; instead, focus on bug zapping and core technology improvements (HTML5, etc.) If Mozilla continues gimping their core software any more, their user base will literally be 0.
Disclaimer: I am an ardent supported of the Suite (SeaMonkey) and everything Mozilla will be doing in the next year will probably completely kill it (ChatZilla, themes, add-ons, etc.)
Example: by this time next year, pretty much nothing you see here will be possible in SeaMonkey anymore thanks to the idiotic decisions from the Mozilla top brass:
You have a misunderstanding of what is going on. Hello, for instance, is not some sort of project is draining resources and/or bloating firefox. It is essentially a WebRTC demonstration. Since WebRTC is a technology that needs to be implemented anyways, and is worth promoting, Hello becomes very interesting.
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.
The capability of addons are being gutted in the name of progress. The new trend towards addons as a toolbar button started by Google Chrome has been disastrous. Extensions like Vimperator/Pentadactyl, that makes deep changes to the way Firefox operate would not be possible under the new system. I think they don't know who their ideal users are any more.
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.
> 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.
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.
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.
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.
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 UI will only get more customizable as a result.
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.
I don't think you need to be worried. If some feature is missing from the new API then get involved with the development and get the feature added. That's what add-on authors are doing (see my other comment).
Mozilla is a serious disappointment. Implementing all what Chrome has and removing all what Firefox has. Including built inside customization features which are available only these days over add-ons.
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's remarkable the extent to which people assume the worst every time this topic comes up. The Mozilla stance has always been that the add-on community is a huge asset but that supporting add-ons based on XUL, XPCOM, and the SDK imposes real costs in security, performance, and maintainability. The plan, intended to keep the benefits while addressing the problems, is to migrate to a new set of APIs -- web extensions. This is meant to be a migration, not a narrowing of the capabilities -- building compatibility for existing Chrome extensions is just the first step in this plan, when that foundation is in place the next steps are to extend the webextensions APIs to keep expanding the set of add-ons that can be written as webextensions.
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?
In my eyes mozilla's stance on security is patronizing towards power-users because it assumes that every addon and every non-root application on the system is potentially hostile.
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?
Mozilla has publicly said several times that they will NOT provide the same set of APIs.
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.
> Yeah it's honestly pretty disgusting. Mozilla's strong add-on system has been one of their largest advertisable features for /years/. Just because a bunch of people have switched to inferior webkit/blink based browsers doesn't necessarily mean that the opposition's technology is superior.
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.
> 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.
I have been thinking that the move to Servo and browser.html is a good time to do things like restore customizable toolbars, since the UI would need to be rewritten anyway.
I've used Firefox since about 2001 when it was in beta and I agree with those that say this isn't an improvement. It seems like control. You need Mozilla to approve of any advanced API you may need access to.
It's probably high time to write a libre browser that focuses on being completely customizable. And not focus primarily on speed. I'm bewildered by those who are deadset on that over all else, it just serves into the goals of for-profits who can dump tremendous resources into optimizing to bamboozle away freedom.
Freedom doesn't cost millions of dollars. A libre Vivaldi, with a tighter feature scope (no email client etc) is where it would be at.
I would point you towards this: https://kver.wordpress.com/2015/09/18/on-ad-blocking-trackin...
Unfortunately development is at a standstill right now. More hands on deck are needed. If other people will not participate at first it might not even use CEF as planned.
Using CEF would be great because it will eventually allow it to use both Servo and Blink.
Also worth mentioning is the other (than Vivaldi) let's recreate classic Opera project: http://otter-browser.org/
Of course both of these are very very young projects and aren't really ready to replace Firefox.
I always really wanted a browser that'd be just a bunch of programs adhering to UNIX philosophy and then striving for simplicity. I mean, components interacting together by talking to each other through the simplest means available, with simplest protocols possible, and with every component being freely swappable. But without a DIY approach to things - instead, trying to bring a Firefox/Chrome-like experience by default, but being hackable and with everything very loosely coupled under the hood.
uzbl is somewhat close, but it's not really portable and still a has a pretty big monolithic webkit engine component, that handles rendering, scripting and networking.
I would also prefer to have the extensions debugging controls available in the about:addons page as opposed to in a separate about:debugging page, similar to how Chrome's chrome://extensions/ page is organized.
Also, I'm curious if there are any plans to implement something like Chrome's event pages [2] as an alternative to having a background page running constantly for extensions that don't require a long-running process?
[1] https://github.com/lewisl9029/just-save-webextension
[2] https://developer.chrome.com/extensions/event_pages