Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Such a post at that time would have greatly improved people's response to the change. Instead what we usually get is a PR sanitized gobbledygook which occupies space without speaking much at all. Now a similar thing is happening with Firefox Android and their extensions. Firefox can easily run most extensions but it's hidden behind a config in a canary release of the browser. No doubt there are some good reasons for it but we simply do not know. Ultimately this is a fault common among almost every product designer. They refuse to explain their decisions fearing (perhaps justly) that they may be proven wrong. Many such cases


> Now a similar thing is happening with Firefox Android and their extensions. Firefox can easily run most extensions but it's hidden behind a config in a canary release of the browser. No doubt there are some good reasons for it but we simply do not know. Ultimately this is a fault common among almost every product designer. They refuse to explain their decisions fearing (perhaps justly) that they may be proven wrong.

There were no good reasons for Mozilla to restrict extensions on Firefox for Android. It was a stupid decision that alienated Firefox's user base on Android with no real benefits.

However, Mozilla has finally listened to the negative feedback and custom add-on collections are now available on Firefox Beta for Android:

https://www.ghacks.net/2022/10/20/firefox-beta-for-android-n...

Mozilla also said they would start working on WebExtensions on Firefox for Android this year. The goal is to have feature parity with desktop Firefox, which includes retaining the Manifest v2 features that uBlock Origin uses:

https://blog.mozilla.org/addons/2022/12/15/new-extensions-av...

While Mozilla has made numerous missteps in the past, it looks like they're finally moving in the right direction.


However, Mozilla has finally listened to the negative feedback and custom add-on collections are now available on Firefox Beta for Android

Anything to avoid putting a useful feature in a stable release or making it convenient, I suppose...


The API being unfinished, meaning web extensions could fail in random, unexpected ways, sounds like a good reason to me?


No reason why it can't be hidden behind a WARNING:MAY BREAK or about:config. But they implemented it in such a roundabout manner. Anyways the issue is not the decision but rather the communication about it. Ideally a dev post about this could have satisfied a lot of people but they chose to go with the PR soup method. It's not even that these are exclusive, include a link to dev post in the soup


https://blog.mozilla.org/addons/2020/09/02/update-on-extensi... and https://blog.mozilla.org/addons/category/mobile/ ?

> We looked at add-on usage on Android, and made the decision to start by building support for add-ons in the Recommended Extensions program that were commonly installed by our mobile users. Enabling a small number of extensions in the initial rollout also enabled us to ensure a good first experience with add-ons in the new browser that are both mobile-friendly and security-reviewed.

And progress is on the MDN: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...


When you look at the entire history of how Mozilla handled the Firefox for Android "Daylight" (version 79) refresh, these excuses were not good reasons.

Versions of Firefox for Android before 79 had the same access to extensions as desktop Firefox. The entire addons.mozilla.org site was available on stable and persistently sideloading could have been enabled on beta via about:config.

Since version 79, Mozilla has reduced the thousands of available extensions to less than 20. While uBlock Origin was one of these extensions, removing the majority of Firefox for Android's tens of thousands of extensions stripped away Firefox's best competitive advantage on Android and infuriated many users. This has been the case for the last 2.5 years, and is a regression in the browser.

Mozilla introduced the onerous add-on collections workaround on only the nightly channel in version 83. However, the nightly channel is not stable enough for regular use, occasionally crashing (with no extensions installed). Forks of Firefox for Android (such as Mull) introduced the feature into stable versions with no ill effect. While extensions on Android were not able to access desktop-only features (such as containers), the user feedback showed that the extensions on addons.mozilla.org were as stable and secure on Android as they were on desktop. Mozilla provided no legitimate reason for why the stable channel of Firefox was locked down in light of this user feedback.

Mozilla ignored or rejected user-initiated requests to approve additional extensions for Android, and the total count of approved Android extensions is currently at 16, with persistent sideloading of extensions not allowed. In contrast, desktop Firefox has 108 "Recommended Extensions", 30,255 total extensions, and access to persistently sideloaded extensions (via a setting). The restrictions on Firefox for Android turned users who wanted access to non-approved extensions away to other forks and browsers that supported them, at no benefit to users who did not use these extensions. At a minimum, adding a setting to enable access to all of addons.mozilla.org would have taken little effort to satisfy users who wanted to access non-approved extensions without affecting users who did not need them.


What also annoys me is they disabled about:config on the Firefox for Android Stable release..


The product designers don't realize that a lot of the backlash comes from the technically-minded audience, and that their usual approach of highlighting user benefits only further fuels distrust among that vocal community.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: