[danShumway]

> In the absence of a true standard for browser extensions, maintaining compatibility with Chrome is important for Firefox developers and users.

About as close as Mozilla can come to outright saying, "Chrome is big enough and we're small enough that what they do _is_ the standard."

Still, it's encouraging to see that they're not removing the blocking API for now. I kind of hope this does push a few adblocker extensions to abandon Chrome.

[zzzcpan]

I find it rather discouraging to hear they are not removing the blocking API for now. It's basically an empty statement, not reassurance. They still may or may not remove the API, they don't want to promise anything or show any commitment to users' needs and priorities.

[wtallis]

It's basically the same as what happened two months ago with Firefox for Android being EOL'd pending a major re-write that may or may not support extensions. Mozilla is not willing to publicly commit to keeping their key features alive, and they keep hinting at the possibility that they will be leaving users behind in an attempt to be more like Chrome.

[lol768]

And the other point of view, directly from Mozilla:

> We're certainly aware of how significant ad blocking extensions are. This release required a great quantity of features with only a six month timeline until now.

> We already support a very limited set of the WebExtensions API to offer features like Reader Mode. Rest assured that more features will land in the coming months.

Source: https://news.ycombinator.com/item?id=20298143

This reads like FUD to me. The dev team know how important extensions are to their users. Can you provide a source that implies Fennec will be EOL before Fenix has extension and/or ad-blocking support?

[mjw1007]

In that discussion (and indeed in the message you quote), the mozilla developers had every incentive to say, if it were true, « we have decided not to replace fennec with fenix on Android until fenix supports ad-blockers ».

They very visibly didn't take the opportunity to do so.

From what I can make out on github, they're planning to replace fennec with fenix around the time the next ESR comes out (which I think is early 2020), and there isn't currently a project in progress to add the necessary web-extension support to fenix.

[lol768]

Thanks for this.

>From what I can make out on github, they're planning to replace fennec with fenix around the time the next ESR comes out (which I think is early 2020), and there isn't currently a project in progress to add the necessary web-extension support to fenix.

Would you mind linking the GitHub issues that have lead you to draw this conclusion, so I can take a look?

[mjw1007]

https://blog.mozilla.org/futurereleases/2019/06/27/reinventi... says they were planning in June to have a "feature-rich, polished" fennec release "this fall".

https://github.com/mozilla-mobile/fenix/issues/879 "[Meta] Fennec -> Fenix Transition" appears to say the transition will happen in Q4 2019.

The Android releases of fennec used to be updated for each Firefox release, but moved to ESR with the most recent ESR release. I think that means that since then nobody has been keeping the Android port working as changes come in (but ESRs are supported for a year or more, so maybe I'm wrong to think that the date of the next ESR release is relevant).

https://github.com/mozilla-mobile/fenix/issues/574 is about web-extension support; the recent updates say:

« Product is looking into feasibility » « Tentatively adding needs:gv label until we know what additional GV work will be needed to support general purpose extensions. »

The issue is labelled 'Feature:FennecTransition' and 'feature request'. It isn't labelled 'should', and some other 'Feature:FennecTransition' issues are.

It isn't clear to me whether they're planning to release a new version of "Firefox" on Google Play that uses the fenix codebase, or release fenix as a separate app and declare that the fennec one is obsolete.

https://github.com/mozilla-mobile/fenix/issues/879 and https://github.com/mozilla-mobile/fenix/issues/934 have some interesting hints, but I can't tell what they've decided.

[Vinnl]

Perhaps interesting: this post that implies that implementing full extension support might not be that much work: https://sammacbeth.eu/blog/2019/09/04/geckoview-extensions.h...

[Jonnax]

A rewrite that is faster than Chrome for Android.

[hajile]

It may be faster than Chrome on Android, but it's certainly not faster than Firefox on Android with adblockers. Not loading/parsing multi-megabytes of Javascript and images is huge. Loads of ads these days incorporate entire JS framework toolchains resulting in a binary bigger than the page they're being injected into. Eliminating a few ads and the rest of your browser could be a lot less efficient and still perform well. That's all before discussing how adblockers also reduce who is tracking you everywhere.

[tgsovlerkhgsel]

In my experience and limited testing, even with warmed-up caches, Chrome (without Adblocker) was faster than Firefox (with or without Adblocker), sadly.

I still use Firefox due to the security benefits of ad blocking, but I don't find the experience particularly enjoyable (although, thinking of it, it may have either significantly improved in the past ~half a year, or I just don't notice because of a more powerful CPU in my new phone).

[Jonnax]

It certainly is faster than Firefox for Android.

There are benefits to adblocking of course.

But there's no point lying.

[bscphil]

Eh. That may be the intent but they aren't there yet. I tested Firefox Preview on Speedometer 2.0 and got the same result I did with Firefox for Android 68. Chrome gets double the score (runs per minute) on my device.

[Endy]

What they should be saying is, "No, what Google is doing is Wrong with a capital WRONG and we're not going to accept their wishes in closing off what's left of the open Web."

But then they'd have to give up all their Google funding. And they're way too cowardly and corporate to do that.

[tomComb]

> "closing off what's left of the open Web."

Seems a little over the top to me!

Also, Mozilla is very good at standing up to Google. They beat them on webasm, rust is arguably supplanting go, and most of all, it was Mozilla that effectively killed web components which were very dear to Google.

[hu3]

> rust is arguably supplanting go

Two very different languages with very different goals. Neither want nor ever will suplant the other.

[sjwright]

Rust is challenging C++ fairly head-on.

Golang is challenging Java, C#, Python, nodejs etc. It was also supposed to challenge C++ but based on how the language turned out, if that is ever true then C++ probably wasn't the right language for that project in the first place...

[atroche]

How did Mozilla kill web components?

[Ygg2]

> adblocker extensions to abandon Chrome.

Ha. As if that will ever happen. They'll probably just pivot to something else.

The reason Chrome can try to ditch ad blockers is that they are big enough, that your only choice is Chrome or GTFO.

[Iolaum]

Your choice can well be firefox and chrome as a fallback when a website doesn't work and you care enough to bother opening chrome for it. Chrome has already ditched adblockers on mobile, firefox with adblockers and reader mode is a MUCH better mobile web experience.

[jefftk]

> Chrome has already ditched adblockers on mobile

nit: chrome has never had extensions (or ad blockers) on mobile

(Disclosure: I work for Google)

[SquareWheel]

That's not even a nitpick. The parent got it completely wrong.

If Chrome mobile never supported extensions, then it's false to claim they "ditched" them.

[awalton]

From the original post, it's more like a language parsing issue - Chrome was original a desktop-only application and it had extensions. When it was ported to Android, they ditched extensions, as well as jettisoning numerous other features.

Thus, not "completely wrong."

[michaelmrose]

They being an ad company were smart enough not to ever allow the camel to get its nose under the tent.

[Ygg2]

> firefox with adblockers and reader mode is a MUCH better mobile web experience

Oh, I fully agree. But just having a better, faster, less ad ridden browser is not enough. The sheer networking effect is propping up Chrome on Android.

I only had a few issues with some videos playing.

[clairity]

do you really need the fallback? i've yet to need chrome for anything, since i rarely use google products other than maps.

i've found the use of google captcha on governmental, financial, and some commercial sites frustrating though. i'll abandon a site that has google captcha if usage is anything less than critical.

[Rebelgecko]

Like you alluded to, some websites perform much better in Chrome (in particular Google's own websites, but there's some other offenders like roll20.net).

There's an FF extension called Buster made someone here on HN that helps workaround Google's current generation of captchas. It doesn't work 100% of the time, but the success rate is still higher than doing it myself.

[iamnotacrook]

Some sites need NoScript disabled to work. Even using the "temporarily trust everything" option doesn't work. Since it's easier to just paste the URL into chrome than disable a plug-in and remember to re-enable it later, I do that.

[ferzul]

linkedin doesn't work for me on firefox, so i rarely even attempt to use it. but if someone a care about wants to link to me, i have to use chromium for that.

[clairity]

that's odd. does the whole site not load, or just certain features don't work?

i use firefox with all kinds of privacy/blocking extensions and can access linkedin just fine (as long as first-party javascript can execute).