Allow sideloading addons on Nightly that use supported WebExtension APIs

[esjarc]

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

[sheikh-azharuddin]

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🤔

[cadeyrn]

One thing I don't understand fenix is built on same engine as desktop 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.

[sheikh-azharuddin]

One thing I don't understand fenix is built on same engine as desktop 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 😣😒 Technically is it not possible to reuse the webextensionapi code of fennec in fenix? You are the expert I am just a user with suggestions 😅 don't mind pls.

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 What is the difference between firefox for Android beta and firefox preview? And difference between firefox nightly for developers and firefox preview nightly for developers?

I think firefox beta= firefox preview Firefox nightly= firefox preview nightly.

[cadeyrn]

I see the fennec do supports all recommended add ons... Would like to see the same in fenix 😣😒

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.

You are the expert I am just a user with suggestions

I am also just a user. 🙂

[sheikh-azharuddin]

I see the fennec do supports all recommended add ons... Would like to see the same in fenix 😣😒

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.

You are the expert I am just a user with suggestions

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? 😊

[LittleAngelwings]

@sheikh-azharuddin

look here for the Addon names :) https://github.com/cadeyrn

[ghost]

I think firefox beta= firefox preview Firefox nightly= firefox preview nightly.

@sheikh-azharuddin Yes, you are correct. One of the developers from Mozilla confirmed it.

Refer this comment: https://github.com/mozilla-mobile/fenix/issues/9039#issuecomment-638244738

[liuche]

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.

[esjarc]

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.

[cadeyrn]

That's very unfortunate to hear

This is no news at all.

Will more add-ons be supported in the future?

We want to ensure that the first add-ons supported in the new Firefox for Android provide an exceptional, secure mobile experience to our users. To this end, we are prioritizing Recommended Extensions that cover common mobile use cases and that are optimized for different screen sizes. For these reasons, it’s possible that not all the add-ons you have previously installed in Firefox for Android will be supported in the near future.

Will add-ons not part of the Recommended Extensions program ever be supported on the new Firefox for Android?

We would like to expand our support to other add-ons. At this time, we don’t have details on enabling support for extensions not part of the Recommended Extensions program in the new Firefox for Android. Please follow the Add-ons Blog for future updates.

https://blog.mozilla.org/addons/2020/02/11/faq-for-extension-support-in-new-firefox-for-android/

[esjarc]

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.

[ghost]

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

[cadeyrn]

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

[esjarc]

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

[liuche]

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.

[sheikh-azharuddin]

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.

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

[ghost]

@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. Bypass Paywalls isn't available on the AMO(I don't exactly know why it isn't available). If I want to install it then what choice will I have been left with even when the relevant WebExtension APIs became available?

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!

[dannycolin]

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

You don't need to use AMO even if there's no sideloading capabilities supported. You can sign your extension with web-ext and self-distribute it outside AMO.

[esjarc]

@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.: More power to you. Open source. Open minds.

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?

[dannycolin]

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.

[teohhanhui]

@dannycolin

You don't need to use AMO even if there's no sideloading capabilities supported. You can sign your extension with web-ext and self-distribute it outside AMO.

Does that work in stable? If not, allowing the user to change that would be a good compromise (though it creates a huge problem of no auto updates, which is not ideal). It'll unblock the migration of many power users (such as myself) from Fennec to Fenix.

[revad]

My use case for sideloading is for addons that I have developed myself, usually for a single website.

This, for example: https://addons.mozilla.org/en-GB/android/addon/mudcat-browser-tools/ That addon never had more than twenty users. The mudcat website was built in 1996 and is pretty much unchanged apart from google ads (it's not only pre-mobile, it's pre-CSS). My addon makes it usable on small mobiles. I (and a dwindling group of fellow pensioners) use this addon every day.

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!

[ghost]

I hope someone at Mozilla reads your comment and considers the importance of side-loading add-ons!

---

And yes, the comment you see here: https://github.com/mozilla-mobile/fenix/issues/11308#issuecomment-641073165, https://github.com/mozilla-mobile/fenix/issues/11308#issuecomment-642119416 on this issue were made by me, they are from my previous GitHub account.

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.

[filips123]

@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 about:config support (#7865), would be regression for many Firefox for Android users. This could cause them to stop updating Firefox and using old and insecure version, or switching to alternative browsers.

Update: Some details how I think support for addons should be done to ensure most compatibility and prevent breakage:

• Loading addons from AMO which use supported APIs: First supported by default only on beta and nightly. If no big problems are reported by users, also support it by default on stable on next release.
• Loading signed addons from third-party websites: Could be enabled by default on beta and nightly, and supported but disabled by default on stable. Enabling this on stable could either be done via about:config (which should be enabled on stable), or via "developer options" (see #11639). After some more time, this could be enabled on stable if it won't cause problems.
• Loading unsigned addons from third-party websites: Supported, but disabled by default on beta and nightly (like it is on desktop). I donn't think this should be supported on stable (it also isn't on desktop version), or it should be well hidden.

[nbmrjuhneibkr]

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.

[dbenjaminmiller]

Let it be put this way. I have extensions which I can already test while tethered using web-ext. They work. I know they work. But for some reason, Mozilla seems adamantly opposed to letting me test these extensions while not tethered to my computer. Everyday usage of an extension is extremely important when it comes to testing it! It's extremely anti-developer that the team refuse to allow the sideloading of extensions, at the very least on beta/nightly. They've put up a walled garden, not only for the typical end-user, but for developers as well.

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?

[creesch]

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.

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.

We would like to expand our support to other add-ons.

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.

[robsmith11]

@liuche You said nearly 2 months ago that a solution to this is allowing side loading on Nightly. Why the delay in a decision?

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.

[andreicristianpetcu]

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.

[andornaut]

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.

[robsmith11]

@liuche Please at least state what the plan is. Otherwise I'm going to keep spamming this issue until Mozilla stops ignoring it.

[akdor1154]

EDIT: apologies, not the right forum.

[andreicristianpetcu]

web-ext run does not allow me to execute extensions anymore :(

web-ext run -s . -t firefox-android --android-device=b0254ffd --firefox-apk org.mozilla.fenix

[creesch]

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

[andreicristianpetcu]

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.

[teohhanhui]

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.

[robsmith11]

@ekager @boek @sblatz @NotWoods @mcarare @colintheshots @pocmo @liuche

Could someone at Mozilla please comment on this issue about what the plan is? By continuing to ignore the concerns of the community, you're going to end up pushing more people away from Firefox.

[yan12125]

you're going to end up pushing more people away from Firefox.

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 [2] https://f-droid.org/packages/org.mozilla.fennec_fdroid/

[caitmuenster]

Could someone at Mozilla please comment on this issue about what the plan is? By continuing to ignore the concerns of the community, you're going to end up pushing more people away from 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.

[kbrosnan]

Closing as a duplicate of #14034