Allow sideloading addons on Nightly that use supported WebExtension APIs #11308
Comments
|
I don't think they will add full extension support... The fennec version has too many feature but one thing missing is bottom address bar which is present in fenix and but again fenix has too many features missing- like all recommended add on support, save page as pdf, customize top sites, sites notification. One thing I don't understand fenix is built on same engine as desktop version..so what's the issue in adding add on support like fennec version🤔 |
Same rendering engine does not mean that the same WebExtension APIs are available in GeckoView. Also note that Desktop devices and smartphones are totally different, they don't have the same UX concepts. So it's not only a technical question to take a WebExtension API from Desktop and implement the API on Android. By the way: Fennec didn't support all WebExtensions APIs of the Desktop Firefox either. |
Thanks Soren for your prompt response as always. I see the fennec do supports all recommended add ons... Would like to see the same in fenix 😣😒 Based on add-ons support in old fennec I am planning to use it for some time... What are your plans to remove it? Requesting you to pls don't remove till extension support is fully added to new firefox same as fennec🙏 One more thing play store has 5 different firefox version... Firefox for Android is fennec I think firefox beta= firefox preview |
I am the developer of one recommended add-on and it's definitively not supported in Fennec, only on Desktop. 😉 Also all kinds of bookmark extensions were never available on Fennec because Fennec never got the bookmarks APIs. And there are at least two recommended bookmark add-ons for Desktop.
I am also just a user. 🙂 |
I miss the add ons like decentraleyes ,clear url, google search fixer, saml tracer. Apart from that fenix has too many issues- buggy long press, reader mode icon missing in url bar, download progress and status. So UI wise new fenix looks really good but feature and usability wise old fennec is better. Also tab arrangements in fennec is much better than new fenix... Now coming to you...I don't think you are average users like us...I feel you have some really good development skills and know better than any normal browser user😅🙏 Btw what is the add on name which you have developed? 😊 |
|
look here for the Addon names :) https://github.com/cadeyrn |
@sheikh-azharuddin Yes, you are correct. One of the developers from Mozilla confirmed it. Refer this comment: #9039 (comment) |
kglazko
added
feature request 🌟
|
Hi there, thanks for filing this issue. Currently, we're exposing new APIs needed by addons, so new addons that use those APIs will automatically become available over time - however, allowing any arbitrary addon to be installed (via a xpi) is both a security risk, as well causes performance problems. Fenix already includes some of the most popular addons, so please follow along as we add more. Going to close this issue bc we're not going to support this right now. |
|
That's very unfortunate to hear, as the only way to install extensions in Fenix will be to use the AMO walled garden or to install a Fenix-compatible xpi in Fennec and then upgrade to Fenix. At least good to know that Firefox for Android will no longer be a browser that suits my requirements and I will have to move to a different browser once Fennec reaches end of life. |
This is no news at all.
https://blog.mozilla.org/addons/2020/02/11/faq-for-extension-support-in-new-firefox-for-android/ |
|
But this quote refers to extension compatibility and not about sideloading? A first step could have been to allow sideloading of all the supported extensions. Once general extension support is finished, sideloading for arbitrary extensions could have been implemented. You could disable the sideloading ability by default (but include an about:config switch for example) if security is a concern. |
|
@liuche Can you please confirm that if Mozilla won't be allowing side-loading extensions on Fenix? if so don't you think this goes against Mozilla's principles of giving control and choice in the hands of users. Or this is just the case for now? Or will you handle it just like the Firefox version for desktops/laptops computers that allows add-ons installation through AMO and side-loading through a website but not through an xpi file. |
|
@esjarc Although the quote is not explicit about the installation of XPI files it means that only recommended add-on can be installed and this logically excludes the installation of arbitrary extensions via XPI files. It was also said that they want to expand their support to non-recommended add-ons. Then will be the right time to talk about the installation of XPI files in my opinion. But right now they don't have details (as announced) so this request is not really actionable in the near term. @liuche also said: "close this issue bc we're not going to support this right now". Maybe things will change in the future but right now it won't happen and "at this time, we don’t have details". (to be clear: it's a quote from the announcement, so "we" is "Mozilla", I am not part of "we", I am a user like you). WebExtension APIs are still being implemented and Mozilla focuses on a selection of recommended add-ons. It takes time to build a great add-on experience and I think it's totally okay to go one step at a time. First there were no add-on support at all, then there was uBlock Origin, then there were five additional add-ons and there will be more in the future. But there are still APIs missing. In the meantime you could suggest Mozilla add-ons you need. While it's not the same as the option to install arbitrary add-ons it's more realistic in the near and probably mid term to get this supported. |
|
@cadeyrn The only thing I can say about this is that sideloading capabilities are an essential feature for me (no matter which extension APIs are finished already and which aren't) and I just won't use a piece of software that implements a walled garden (unless I don't plan to use anything from that walled garden). This issue was not created with the intention to sideload incompatible extensions and it is also not about missing extensions. I created this issue, because I have issues with walled gardens and I wanted to see the ability to retreive extensions from sources other than AMO (local xpi, websites, etc.). If this feature would have been restricted to signed extensions, I would have requested support for unsigned extensions (xpinstall.signatures.required; also already possible with Fennec). So if Fennec transitions to Fenix and doesn't offer this ability, I will simply move to a different browser (e. g. many Chromium-based browsers are getting extension support at the moment and support sideloading). If this changes sometime in the future, I may come back, but I just won't use it until that's the case. Others may have different priorities, but missing sideloading support is the primary issue I have with Fenix (besides about:config, resource usage and UI issues) and that's why I created this feature request. |
|
Thanks for the thoughtful framing of this, @esjarc! Addons is a heated topic, and it's been frustrating for our team to deal with a deluge of requests for "i need X addon", so I admit I had a bit of a narrow reading of the bug you filed. As for sideloading addons, if framed as: on Nightly, that are supported by the APIs that we expose, that sounds like something that we can support in the future. Going to reopen, and rename this issue to be a little more clear. We will likely never support sideloading on Release (or even Beta) because of the risk of general population users unintentionally installing a problematic addon that breaks their experience, or poses a security risk or performance hit, but Nightly is a more experimental/dev app which fits this use case better. |
liuche
changed the title
liuche
changed the title
Pls add more add ons...6 add ons were added long time ago....we want all recommended add ons atleast for now....in particularly I want decentraleyes and clearURL |
|
@liuche So if I'm understanding this correctly, you are saying that you won't be allowing installation of any extensions that are not in the AMO. Correct? I understand that you're saying that the general population users are not tech savvy and if they install the wrong extensions it'll be a security/performance/functionality breaking issues in the browser. Then why don't you handle it like Android which allows side-loading apps with a switch which warns uses that it'll be a security/data loss risk and allow them to install the apps outside the Play Store. This way they'll know what they're doing. Not allowing side-loading extensions even if they're willing to accept the risks is not okay if Mozilla wants to give the users the choice and control. Just imagine if Google doesn't allow installation of apps outside the Play Store on Android. I don't even wanna imagine it!😨 I have an example here: I use Enpass Password Manager on desktop and they don't have the extension for their password manager on AMO. At that time they wrote a blog post the reason for it being that they wanted to push security updates faster to the extension as soon as possible by bypassing the AMO review times. So in such cases I have to install extensions from outside the AMO. And some extensions are just not available due to the add-on store policies. I'm saying all of this considering that you plan to not allow the installation of extensions on stable channel. Nightly is not where I browse the web all the time because I don't know when the functionality of the browser will break. I have all my browsing on the stable channel, that is where I want to install extensions and use! I strongly believe in what Mozilla does for the web! And I believe that they'll not take away the freedom of choice and control of their users! |
You don't need to use AMO even if there's no sideloading capabilities supported. You can sign your extension with |
|
@liuche Thanks for reopening the issue and taking this issue into further consideration! But as @Ss1113 already explained, I also don't consider support in Nightly to be enough. Nightly is just not suitable to use on a daily basis (e. g. take a look at the recent nightlies with the new tab menu) and I'd like to request support at the very least for the beta branches (about:config is also in enabled in beta). A bit more thoughts I have about the general attitude: In general I don't support and understand the arguments that an end user may install a malicious extension and support for sideloading should therefore be removed alltogether. Even Android allows the user to sideload arbitrary apps by flipping a switch in easily accessible, non-hidden app settings. Android then allows me to install and use any apk imaginable. Even though Android has over a billion users and includes this ability from the very beginning, I don't hear a lot about sideloaded malicious software as a serious issue (actually I have heard more about malicious software distributed via the Play Store than sideloaded apks), the same can be said about desktop Firefox and Fennec. To be honest this sounds more like a theoretical issue to me ... I can understand why you would not want such a feature to be enabled by default, but I can not understand why you would not even give the user the choice to use the software in a non-mainstream way by including a simple setting for enabling advanced features. Taking away this choice and forcing users into walled gardens and predefined use cases does not really match the values that Mozilla promotes on its homepage in my opinion, e. g.: To get back into actual ideas about how this situation could be solved: How about adding some kind of developer settings to Fenix (including stable), which you can enable via tapping on the version number a couple of times (like Chromium for Android)? Within developer options, there should be the following switches: Enable about:config, Enable extension sideloading, Enable unsigned extensions. Would it be worth to open an issue about this idea/feature request? |
I would say yes since they aren't necessarily related. By that I mean, about:config could be interesting for more than just enabling unsigned extensions. It'll also be easier to focus the discussion on more specific use case for each of this options. However, I don't know what's the preferences of the Fenix team in regards to discussion of feature requests on GitHub. Maybe, there's a better place to start those discussions before opening an issue. I know some teams use a mailinglist for that kind of stuff. There's also a room on the Mozilla Matrix server. I'm sure someone there would be happy to point you in the right direction. |
ghost
mentioned this issue
|
My use case for sideloading is for addons that I have developed myself, usually for a single website. This, for example: I have a few more like that - some on AMO, some not. They're not complicated - that one started as a bunch of userscripts. But they're important to me! |
|
I hope someone at Mozilla reads your comment and considers the importance of side-loading add-ons! And yes, the comment you see here: #11308 (comment), And I believe the value of side-loading add-ons cannot be overstated; they are are absolutely necessity in a browser which should be open by its nature. And Mozilla shouldn't hinder that opportunity. They should allow side-loading of add-ons on the stable channel. There's no value in enabling side-loading add-ons in just Nightly versions as the general avarage users won't be using it. |
ghost
mentioned this issue
|
@liuche Can sideloading addons from XPI files and installation of addons from AMO which support supported APIs be enabled? As many others said, many addons cannot be published to AMO, either because of restrictions or because they are meant for private use. And even if they are published to AMO, many of them are targeting very specific user groups, so it is very unlikely they will become recommended extensions and supported in Fenix with current restricted list of supported addons. Lack of support for installation of all addons from AMO and sideloading them, along with Update: Some details how I think support for addons should be done to ensure most compatibility and prevent breakage:
|
|
If the browser is capable of running the extension (and I don't see a reason why Fenix wouldn't be able to run most WebExtensions), Mozilla shouldn't be restricting users from installing it (and not just on Nightly, but on all branches). There's no way for "Recommended Extensions" program to target all use cases, so it being the only way to get extensions on mobile is completely unacceptable. |
|
Let it be put this way. I have extensions which I can already test while tethered using I am literally saying: I demand no additional API support. I just want to be able to test in my everyday usage. That is really the least I could ask for. Why would you not flip that switch? |
This is the problem I am facing with one of my extensions. The target group is very specific so it will never qualify based on that which is unfortunate as we do have a select group of people specifically using the extension on their phone without issue until the forced update. This is made even more unfortunate by the fact that I have been able to confirm that my extensions works perfectly fine on fenix and has been working fine for several months now but I can only do so as long as I am tethered to a desktop computer. This also isn't the first time I tried to raise this concern, in fact I have tried to talk about it around half a year ago. Some more unfortunate context can be found in #5315. Specifically this comment and the resulting discussion resulting in this statement. This seems to have not changed at all as in #13059 basically the same is repeated.
The problem is that without context it doesn't mean much at all. Does it mean more extensions are going to get verified or does it mean that at some point it will be made possible to install any signed extension like was possible before? So there is no clarity at all about what their plans are in this regard. |
|
@liuche Why is Mozilla ignoring the increasingly frustrated group of users commenting in this issue? This isn't some large development effort that requires resource commitment. It's a simple decision. Mozilla needs to make the decision and explain to the community their reasoning. |
|
Or at least make a project/meta bug with the required work so we can see what remains to be done. Maybe we can chip in on the effort. |
|
I developed an add-on for which I am probably the only user. This add-on significantly improves my experience of browsing the web on my mobile devices. It is important to me. I'm happy to side-load this add-on or jump through whatever hoops Mozilla thinks is necessary. Please allow me to continue to use this add-on on future versions of Firefox on Android. |
|
@liuche |
|
EDIT: apologies, not the right forum. |
|
web-ext run does not allow me to execute extensions anymore :(
|
|
Is that on stable or nightly? Either way that makes it effectively impossible for extension developers to even test if their extensions would potentially work and therefore impossible for them to see if they could possibly apply for recommended status. I am really not sure what is going on here anymore as the communication about it has been virtually non existent besides the vague non statements I mentioned earlier |
|
I see the devs are mostly fixing bugs. I guess it was a tight deadline and there was a lot of presure on them recently. Fixing bugs is not fun. They probably wish they could add features and APIs since they are probably also Firefox users. Let's not put more presure on them on GitHub. |
|
This is not about the devs. This is about how Mozilla as an organization has decided to (not) engage / listen to its users. This trend has been going on for a while now. They've been taking more and more of a walled garden approach, taking control away from users. You can see that consistently in different Firefox offerings. |
There is an alternative - moving away only from the new Firefox [1] and installing Fennec (the old Firefox) ESR 68.11 from F-Droid [2]. Thanks to the awesome Firefox Sync service, almost all settings are preserved after switching to the old version. Also, both browsers can co-exist on the same phone, so you can switch back to the new Firefox after it is improved. Somehow I cannot use the debugger on Firefox 79.0 to connect to Fennec 68.11, though, so I need to manually installing XPIs. [1] https://play.google.com/store/apps/details?id=org.mozilla.firefox |
Hi @robsmith11, I hear your frustration. Github's not the best place for leaving feedback/asking questions; we've got a thread on our community forum for that. :) We would like to enable support for more extensions and we're still evaluating the best way to do that without running into some of the compatibility and security issues we saw on Fenix. One option we are looking into is enabling general extension support on a pre-release channel (like Nightly or Beta). We haven't made any decisions yet so there are no details, but we will announce them on the Add-ons Blog when they are available. |
data-sync-user
changed the title
data-sync-user
changed the title
data-sync-user
changed the title
kbrosnan
changed the title
|
Closing as a duplicate of #14034 |
What is the user problem or growth opportunity you want to see solved?
With Fennec it is possible to place an extension (xpi file) anywhere in Android's user storage (e. g. /storage/emulated/0/Download/ublock-origin.xpi). By tapping on the file from a file manager you can open the xpi in Fennec and you get the option to install the extension.
Unfortunately there is currently no way to sideload an xpi with Fenix (I have even tried an HTML page that links to an xpi). As this is something that was possible on Android for years already, I would also like to see that feature implemented in Fenix.
How do you know that this problem exists today? Why is this important?
I use this feature with Fennec and tried to do the same on Fenix and noticed that it does not work.
Who will benefit from it?
Anyone who wants to sideload xpi files (e. g. extensions outside of AMO, offline usage, etc.) and users coming from other browsers (e. g. Kiwi Browser, which allows sideloading of crx extensions, and browsers implementing Kiwi's extension patches (e. g. Brave, ungoogled-chromium)).
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: