News for hackers. Stuff that matters.

A comment on Firefox 68.0. Parent comment

Re:Firefox 68.0 by lol768 on Tuesday July 09, 2019 @12:40PM (#20393670)
And the other point of view:

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

[ Parent | on HN ]
Re:Firefox 68.0 by zamalek on Tuesday July 09, 2019 @12:58PM (#20393927)
> FUD

I originally commented there and expressed how they were underestimating the importance of ad blocking. One of the issues I pointed to as evidence (https://github.com/mozilla-mobile/fenix/issues/96) has since been re-prioritized to Q3.

They seem to have heard the message.

[ Parent | on HN ]
Re:Firefox 68.0 by JeremyNT on Tuesday July 09, 2019 @12:48PM (#20393789)
> This reads like FUD to me. The dev team know how important extensions are to their users.

Just because they know how important it is doesn't mean they care.

I'm sure Google also knew how important ad blocking was to many Chrome users when they decided to remove that functionality from their browser, too.

[ Parent | on HN ]
Re:Firefox 68.0 by BiosElement on Tuesday July 09, 2019 @01:38PM (#20394469)
uBlock seems to work just fine, not sure why you're claiming they removed it.
[ Parent | on HN ]
Re:Firefox 68.0 by wtallis on Tuesday July 09, 2019 @01:58PM (#20394731)
He's not claiming that they removed it. He's referring to the fact that Google announced their intention to remove the APIs that uBlock relies on. They haven't followed through with the plan yet, but neither have they completely backtracked. See eg. https://www.androidpolice.com/2019/05/29/google-still-plans-... and reports that they'll continue to provide that functionality only to enterprise users: https://9to5google.com/2019/05/29/chrome-ad-blocking-enterpr...
[ Parent | on HN ]
Re:Firefox 68.0 by techntoke on Wednesday July 10, 2019 @12:33AM (#20399166)
Chrome devs made it clear that just because the API is changing that adblocking will still be supported and it will be faster. Sometimes APIs change.
[ Parent | on HN ]
Re:Firefox 68.0 by krageon on Wednesday July 10, 2019 @04:57AM (#20400299)
The API was crippled, not changed. There is a fairly lengthy explanation of how it is bad and why by the author of uBlock Origin: https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss...
[ Parent | on HN ]
Re:Firefox 68.0 by sascha_sl on Wednesday July 10, 2019 @02:16AM (#20399541)
being able to decide for every request with code vs a limited number of patterns you can pre-populate is not an equally useful API replacement
[ Parent | on HN ]
Re:Firefox 68.0 by icebraining on Tuesday July 09, 2019 @01:16PM (#20394199)
Chrome didn't remove ad-blocking.
[ Parent | on HN ]
Re:Firefox 68.0 by kevin_b_er on Tuesday July 09, 2019 @01:44PM (#20394539)
More "features will land", not necessarily extensions. They have limited internal extensions API because several of their features were implemented with bundled extensions, but it doesn't talk about extensions/addons themselves.

And, yes, there's the "ad blocking" issue: https://github.com/mozilla-mobile/fenix/issues/96

What does it actually say? The requirement is "Integrate/support for different adblock lists (see Focus)".

So you can have certain ad-block lists, but not the actual customization and not uBlock Origin.

[ Parent | on HN ]