I can't make any specific commitment, but there's a lot of time between now and Firefox for Android going EOL (and we haven't committed to specific timing for that, either.)
However, we do have concrete plans for supporting adblocking as a built-in feature in the near future (https://github.com/mozilla-mobile/fenix/issues/96), which should make Preview more palatable to folks who rely on add-ons for that, even if only as a stopgap.
More fundamentally, when considering major features like add-on support, we want to take the time to ensure that we're getting our design right at all relevant levels: Firefox Preview, the underlying GeckoView library, and the Gecko engine itself. And though development on Preview moves quickly, there's still a lot of design and development work yet to be done.
> However, we do have concrete plans for supporting adblocking as a built-in feature in the near future
reading this almost makes me cry because that is the same bullshit google is telling us with chrome.
Firefox is not supposed to block ads! Firefox only has to provide an interface for addons so they can do whatever(!!!) they want (for example blocking ads or installing malware on your system).
Please don't sacrifice our freedom for a wrong understanding of security (like that addon-signing you pulled lately).
I can't agree with this more. I have already moved off of Firefox on the desktop. If this is the destination of Firefox mobile, there is absolutely no use case for it.
Most users will only use an ad blocker that is built-in. You should consider how elitist it is to confine ad blockers to users who know and trust certain extensions vetted by their community, but not the remaining extensions which have been a minefield.
Having a built-in ad blocker doesn't hinder an app from also accepting extensions which block ads.
Originally I wasn't even concerned about an adblocker being built-in. I
was just afraid that it will be used as an argument against more
powerful extensions.
But you brought up another point: I think it is in the nature of an
adblocker, that it MUST be "elitist" to be actually useful. If every
browser does "adblocking" by default, the ads will just adapt. That
will be as useless as the HTTP-Header "dont-track-me".
Good, let ads adapt. Then the adblockers adapt once more. And so on, and so forth. If ads were delivered by the same source/domain (ie. it wasn't outsoured to an ad network who also do profiling) people would have less issues with them.
Not wanting my workflow broken and replaced with inferior software is "elitist"? I don't think so. I hope your attitude isn't prevalent inside of Mozilla. You can say that breaking existing extensions isn't necessary, yet that's exactly what has already happened once and seems like it will happen again.
Yeah, a lot of it is elitist. In other parts of this thread people are complaining about Vimperator being broken by the switch to WebExtensions.
The switch to WebExtensions allowed all the excellent performance improvements we have been seeing in Firefox over the last year. So it improved the performance for everyone, and broke a feature that a small minority used. That minority is a highly specialized, highly trained, bunch.
If you think that features that benefit a small elite group of users should trump improvements for all, then I think that is an elitist attitude.
Also, here there is absolutely no talk about changing extension APIs. So I don't see why extensions that work now shouldn't continue working in FF Preview once Extension support is added. The situation is pretty unlike the WebExtension situation.
So yeah, hold their feet to the fire to make sure that things don't regress without need. But also look at what they are trying to do with merging the FF Focus stuff in, and getting a built-in adblocker. They are doubling down on privacy for all. This should be commended.
People are not less deserving of stable software or good UX by virtue of being highly specialized and highly trained. These users, as much as anybody, have every right to be upset when their software experience is degraded, so I reject your premise unequivocally. If opinions like yours are prevalent inside Mozilla, then the organization has gone cancerous and I fear it's days of producing praise-worthy software are drawing to a close.
Consider the following: over the years I have convinced a dozen or two users in non-technical careers to switch to firefox. Most of them do not install extensions, at least for themselves. However, without extensions, I would not have recommended firefox to them in the first place. Firefox's rise in popularity is owed to the word of mouth campaign carried out primarily by people with technical/foss careers or inclinations. Why would I, or anybody, suggest a browser that I do not enjoy using? To suggest software to somebody is to go out on a limb for that software, because if the person you are suggesting it to has a bad experience with that software, your personal reputation will take the hit for recommending it. So why on earth would I stick my neck out to promote Firefox when Firefox is no longer software that cares about the needs of users like myself? If Firefox has adopted a "socially progressive" model of disregarding the needs of technical users because such users have more software-privilege, then they have taken the wind out of their own sails[sales].
(I put the words 'social progress' in scare-quotes because I also reject the premise that infantilizing software is in fact socially progressive. In truth it's socially regressive, since it's effectively technical people deliberately reducing the exposure non-technical users have to technical problems that might challenge them to learn more. The true impact of infantilizing consumer software is to pull the ladder up behind us. Reinforcing and widening the dichotomy between technical and non-technical users is inherently socially regressive.)
Extensions can be a good thing for sure. But they need to be done right. Hacking out some hurried implementation of extensions is how malware and security advisories happen. It is elitist to suggest that the desires of the 3% trump building a good browser first.
Also, the Internet and most technology happens to break existing workflows. We shouldn't assume disruption is bad if the result is an improved version.
> However, we do have concrete plans for supporting adblocking as a built-in feature in the near future
I also work on an open-source project, and I understand where you're coming from WRT decisions that are unpopular on the outside, but make sense when viewed from the inside. But as a user of Firefox, having already gone through one round of breaking extensions I quite liked with no apparent benefit to me as a user, I'm really not enthused about going through another round of this. Adding a built-in ad-blocker is fine, I guess, but I also use NoScript on mobile. Is that going to die when Firefox for Android goes EOL? What benefit am I going to gain by giving up another one of my core add-ons?
I know you can't answer that here and now, but please, seriously consider how this looks from the user's perspective. I love Firefox and I would like to continue to do so.
I think you need to make it clear to your colleagues that you need to strongly reconsider any possibly that you EOL browser a before browser b supports plugins (specifically ublock origin and noscript) as a lot of your core users will simply not use a browser without them. They're not a "nice to have" - they're what they need to even consider using the browser. Otherwise they might as well be using chrome, or one of any number of other browsers.
>However, we do have concrete plans for supporting adblocking as a built-in feature in the near future
I use Firefox because I enjoy the freedom it grants users do modify it as they see fit. If the play here is to turn adblocking into a walled garden feature so you can monetize it either on the user or advertiser site I might as well go back to Chrome.
Not exactly. I understand "EOL" to mean that all support has ended. An EOL'd project is dead, and if anything breaks no one is going to fix it for you. That is not the case for Firefox for Android.
Instead, think of Firefox for Android as a Long-Term Support (LTS) release, like you might see with projects like Ubuntu, Node, or Django.
There are no new features coming to Firefox for Android, but we will keep the 68 branch alive and maintained to ensure that everything keeps working and is secure on Android. We will do this for at least another year, to give Firefox Preview more time to develop and mature.
On desktop, we do something similar with Firefox's Extended Support Release ("ESR") versions (https://www.mozilla.org/en-US/firefox/organizations/). Every year, we pick a version of Firefox that we commit to supporting for a very long time. Last year, it was Firefox 60. So even though Firefox 68 is available, we're still backporting patches and fixing bugs in Firefox 60. This year, Firefox 68 is the ESR version, so we'll support until at least late next year.
One year is a very short time. The fact is that we can't rely on having support to all our add-ons and browser experience in the near future (next 2-3 years) means we have to start thinking about what to switch to. Also, I wouldn't feel comfortable recommending firefox anymore for that same reason. When the time comes to decide whether to switch to fenix or chrome, fenix will need to really impress. It's a bold move from mozilla.
Anyway, I use firefox on Android because of the ad blocker and to avoid AMP. If the new firefox works similarly in that regard, then I might end up switching to that instead.
Thank you (and the other Mozillians) for trying to engage the feedback! Please remember when planning that extensions need time to be fixed, which means there must be significant overlap between when extension support in Fenix shows up and when Fennec actually goes EOL.
However, we do have concrete plans for supporting adblocking as a built-in feature in the near future (https://github.com/mozilla-mobile/fenix/issues/96), which should make Preview more palatable to folks who rely on add-ons for that, even if only as a stopgap.
More fundamentally, when considering major features like add-on support, we want to take the time to ensure that we're getting our design right at all relevant levels: Firefox Preview, the underlying GeckoView library, and the Gecko engine itself. And though development on Preview moves quickly, there's still a lot of design and development work yet to be done.