Fenix: [Bug] Extensions that have not been published for Android are allowed to be installed

[dessant]

Extensions that have not been published by extension authors for Android can be added to AMO collections and installed on Fenix, leading to support requests and negative reviews.

I have been contacted several times about Clear Browsing Data being broken on Fenix Nightly, when in fact the extension has not been published for Android, because the required API is missing.

Please filter out extensions that do not have an Android target on AMO when a collection is loaded in Fenix.

[kbrosnan]

@agi @csadilek do we have an issue/bug about restricting installs to manifests with the correct appIDs? From a quick look I did not see one.

[agi]

I don't think we have one, but the same can happen with extensions that use APIs that are not currently supported in Fenix but are marked as Android compatible, so I'm not sure how much that's going to help.

[dessant]

@agi, marking an incompatible extension as available for Android is a mistake on the maintainer's part, filtering out extensions without an Android target will still help projects that have been published correctly.

[KrasnayaPloshchad]

Every user should claimed whether the extension is designed for Firefox for Android if an user publish the extension at the Developer Hub. This can be reproduced with Save Page WE and SingleFile, during the 68.x release cycle I can see Save Page WE is unable to install and SingleFile can be install directly, but I see both these extensions marked as “Not available on Firefox for Android” after I updated to the latest release, and now I can install them directly in the Nightly release with instructions from Mozilla Blog.

[jvillalobos]

Users that are going out of their way to enable this installation method on Nightly should know that these are unsupported extensions and may not work. The compatibility setting on AMO is not a reliable method to determine what will or will not work. I don't think we should change the current behavior.

[dessant]

@jvillalobos, it is a reliable method when the developer tells you that the extension is not available on Android, and it makes no sense to let people install extensions that are explicitly marked as incompatible.

You don't have to be a power user to be affected by this, the default collection that is being curated by Mozilla employees contains some extensions that have never been published or in any way compatible with Firefox for Android, and they are installable by opening the add-on manager.

[jvillalobos]

The steps needed to enable this feature are not at all trivial. Users can't just flip a switch to enable arbitrary add-ons and shouldn't expect them to work.

[dessant]

Again, the default collection in Firefox Nightly contains extensions that have not been published for Android, you don't have to configure anything to install them.

@jvillalobos, is the Firefox for Android checkbox being deprecated on AMO?

[jvillalobos]

Again, the default collection in Firefox Nightly contains extensions that have not been published for Android, you don't have to configure anything to install them.

That's surprising to me, but I'll let the Fenix people look into and respond to that.

@jvillalobos, is the Firefox for Android checkbox being deprecated on AMO?

We're making some changes on AMO to better support Fenix and that might involve changing how that setting works. It's still TBD, however.

[jvillalobos]

This is the collection that should be the default in the current Nightly. Do you see something different?

[dessant]

Yes, that's the collection which contains some untested extensions.

[jvillalobos]

Those extensions _have_ been tested by us. That doesn't mean they can't have mobile bugs, but they have been specifically chosen because they work on Fenix.

[dessant]

https://github.com/mozilla-mobile/fenix/issues/15784

Would opening a tab with https://github.com/mozilla-mobile/fenix/issues/15840 from the extension when it is installed on Fenix be acceptable as a workaround? I really don't want to continue spending my time on support requests for an unsupported platform, and people usually don't read the AMO description first.

In Fennec it was easy to prevent this issue, but things are changing and I'm afraid extension developers were left for the time being to deal with the fallout.

[clientenq]

Users that are going out of their way to enable this installation method on Nightly should know that these are unsupported extensions and may not work. The compatibility setting on AMO is not a reliable method to determine what will or will not work. I don't think we should change the current behavior.

That would be reasonable if we dont take into account the large amount of complaints and negative feedback for missing extensions and FF providing Nightly with custom selection as alternative. I agree users should be aware what nightly is and is not. Providing Nightly as alternative with so many complains we can expect even normal users start using this and get disapointed (again) by the minimal addon support by FF. Since it does not look like FF will support more extensions soon while users depend on these you can expect users will find alternatives besides using Nightly. So what is a better solution then saying sorry no support or quality there, figure it out yourself to all those users requesting more professional addon support from FF?

[agi]

Again, the default collection in Firefox Nightly contains extensions that have not been published for Android, you don't have to configure anything to install them.

@dessant What unsupported extensions are available in nightly by default?

[dessant]

@agi, I have linked it above: https://github.com/mozilla-mobile/fenix/issues/15784

It was removed right after I've made that comment, though keep in mind that the collection is fetched once and then loaded from a local cache. The extension will be visible and installable from the add-on manager until a new collection ID is created for the curated extension list.

[agi]

It was removed right after I've made that comment, though keep in mind that the collection is fetched once and then loaded from a local cache. The extension will be visible and installable from the add-on manager until a new collection ID is created for the curated extension list.

I don't think that's accurate, IIRC we check the collection every 24h or so.

[dessant]

Regarding the main topic of the issue, how would you move forward? How can developers explicitly signal whether an extension is considered compatible or not, to avoid all the wasted time for everyone involved?

Should the browser_specific_settings manifest key be extended to provide compatibility information for Firefox for Android?