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

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.




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

Search: