Fenix: [Meta] WebExtension Support

[vesta0]

We want to bring WebExtensions support to Fenix and provide our users with the choice to customize their browsing experience.

Follow our progress here on the WebExtensions project Board: https://github.com/orgs/mozilla-mobile/projects/44#card-26664450

[yoasif]

Can you open the Google doc up @vesta0?

[creesch]

I concur, having feature briefs linked in an open source project that only people with access can see seems to go against the open source spirit. If it is an on going internal discussion I sort of understand but having some context here for us eagerly following development would be nice.

[cadeyrn]

@vesta0 As add-on developer I am particularly interested in the APIs you plan to support. What is the best place to talk about the APIs I need to port my add-ons to Fenix?

[vesta0]

@yoasif @cadeyrn @creesch I will share more details as soon as we have them! The cross-functional team is currently discussing various approaches and we should have a plan soon. Thanks for your interest and stay tuned!

[julian-alarcon]

Isn't this a duplicate of this one? https://github.com/mozilla-mobile/fenix/issues/574

[unixandria-xda]

I'm sorry if I seem rude, but in almost every open source project I've seen recently "exploring ways to implement" or similar really just means "if we get really bored we'll do it but probably not"
I'm just going to say that I chose Firefox over Chrome for two reasons on Android: it's not run by Google (privacy concerns) and supports add-ons. Before the speed of Chrome made it preferable. Firefox preview has finally caught up on the speed front so that's no longer a hindrance.
In addition, browsers like Samsung internet support a limited range of extensions in the firm of content blockers, and now kiwi browser (based on Chrome) fully supports extensions.

Please, please do not let this become just another abandoned side project that was ditched in favor of "performance and security" (rough excuse Google uses for no add-ons on Android Chrome), and listen to your users. That's been one of the key differences between Mozilla and Google let's keep it that way

I'll be eagerly watching this issue for updates, keep 'em coming!

[vesta0]

We have started the foundational work. It will be a while before it makes it into the product but you can follow it here :)

[Lusito]

Just want to throw this in as an extension developer:
It would be very appreciated, if the web-extension code could be shared between desktop and mobile.

Currently, you often see support for an API on desktop, but not on mobile. This essentially makes one of my extensions incompatible with Firefox android and the other one only supports a very limited subset of the features of the desktop version. If this was a common code-base, new apis could arrive at the same time.

[andreicristianpetcu]

@Lusito some browser side APIs are platform specific. For example the UI of BrowserAction and PageAction looks totally different on Android vs Desktop. You can always check if an API is available by comparing it with undefined before using it.

if (!!browser.bookmarks.onChanged) {
   browser.bookmarks.onClicked.addListener(handleClick);
}

[Lusito]

@andreicristianpetcu I am aware that some APIs need to be implemented platform-specific.
But one example that isn't easily checked is the hostnames support on the browsingData.RemovalOptions:

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/browsingData/RemovalOptions

You can't check for that with a condition. Aside from the fact, that Firefox doesn't ignore extra properties, but complains about them aggressively by failing the promise (which is in this case good, since my intention to only clear by hostname can obviously not be met when on android).

I don't see why this API needs a different implementation on android and desktop.

[Lusito]

btw. your sample code checks for onChanged, but uses onClicked.

[Juraj-Masiar]

@Lusito You can also just use runtime check to see if you are on Android and then change the behavior accordingly.

// returns a Promise<boolean>
browser.runtime.getPlatformInfo().then(({os}) => os === 'android');  

But I agree, the API support could be better. And I really hope the currently supported API in "Firefox for Android" will be working in the initial version of Fenix.

[andreicristianpetcu]

Is there a feature flag in about config to test this while it gets build?

[TakuyaSama]

This would be fantastic, i can't wait to this feature arrives to stable Fenix/Firefox Preview, i have uninstalled Fennec F-Droid (actual Firefox for Android (Fennec)), and only using Firefox Preview, really impressive, i was using Fennec F-Droid for about 2 years or more, because i really love Mozilla, the privacy and the ability that Firefox for Android provides me to install and use add-ons even on the smartphone web browser.

But the lack of this feature is making me worry, (i'm not trying to hurry, i know the devs and the team is working hard), but the fact is that i have a Mi 9T Pro right now, running LineageOS 10 (unofficial and not stable yet), but the fact here is that this smartphone has a pop up front camera, and it has been about 3-4 times that i'm surfing the Internet at Firefox Preview when the front camera pops up, leaving me a little bit disturbed. This powerless feeling is something horrible, that i hate to feel and something that with Mozilla's software i'm not used to feel.

So just keep working as you're doing right now, i would like to thank you, for the really needed renovation of Firefox for Android you're doing, i just tried Fenix about 1 year ago, but it was unusable to me, so i just waited, but when i tried about 1 week ago, wow, i'm really impressed. You're doing great, keep doing what you know, keep the Internet free and accessible to everyone.

Thank you very much for your fantastic work, efforts and everything you're putting in it.

Receive a huge hug everyone ^^.

[KOLANICH]

that i'm surfing the Internet at Firefox Preview when the front camera pops up

Shouldn't it be under a permission?

[TakuyaSama]

Shouldn't it be under a permission?

Do you mean that the problem i'm talking about is just a permission problem?

PD: I just did it, Fenix crashed after do it, but now i denied the permission to access camera, i can't open a URL with the scan feature at Fenix.

Thanks :).

[KOLANICH]

1. I meant a WebPermission, not an Android permission
2. It is definitely a bug in ff if it crashes after rejecting an Android permission.

[cadeyrn]

Please note that other people get notified about every new comment in this issue and this issue is about WebExtensions… Thank you!

[creesch]

As en extension developer who currently does target Fennec is there a way for me to test out how well my extension does work in Fenix? I saw that uBlock origin has been enabled in the nightly builds but as far as I can tell it isn't possible to install an extension myself from either AMO or XPI file.

However if I look at this support page it seems to suggest that it should be possible:

While some members of the community have discovered that some extensions (Recommended and non-Recommended) inadvertently work in Firefox Preview, we do not recommend attempting to install them until they are officially supported as other issues may arise.

I fully understand the fact that things aren't likely to fully work but I'd like to keep an eye on progress as extension support develops so I can get a better grasp on what is or isn't needed to make our extension work properly once extensions are fully supported.

This because the extension we do develop doesn't have the audience to likely qualify for Mozilla recommended extensions (specifically the general audience bit).

[brampitoyo]

@creesch wrote:

I'd like to keep an eye on progress as extension support develops so I can get a better grasp on what is or isn't needed to make our extension work properly once extensions are fully supported.

I’ll refer you to @kewisch, who may be able to help answer questions around:

• WebExtensions API support: what’s already supported? What will be supported in the future?
• Testing add-ons: is there a way for developers to do it?

[vesta0]

We are currently building API support exclusively for extensions from the Recommended WebExtensions Program.

[pwd-github]

That's an odd decision to me, because there's add-ons that are made for mobile and thus have no use for desktop.

A Fenix specific extension that I desperately need for example is one to switch the existing tab to a private tab and vice versa. Not to mention extensions to clean up the menu (remove collections, create page submenu with report, find, add to home page, add to launcher) such add-ons have no chance of becoming recommended if they can't be used in the first place.

[creesch]

Wait what? Why only those extensions? This is the sort of exclusion I'd expect from Apple or Google, not Mozilla of all organisation.

The extension we develop has a relatively small fairly specific audience so wouldn't be qualified for the recommended extension program as it isn't general enough.
This means that even if our extension would work in theory we still have to tell our users to stick to Fennec because of an arbitrary choice like this.

I would understand not focussing on non recommended extensions but outright excluding them is baffling to me.

In fact finding this out here without further explanation is very much the sort of thing I made #5410 for.

[davi-ro]

That would mean that extensions like Simple Gestures, one of the most useful addons for firefox on android, in my opinion, will not be supported?
This is very disappointing.

[tanriol]

We are currently building API support exclusively for extensions from the Recommended WebExtensions Program.

@vesta0 Could you please clarify this statement? It may be interpreted in a number of different ways ranging from "we have limited manpower and focus on implementing the APIs that the most popular Recommended Extensions require first, but any extensions are welcome and can be installed" and down to "we believe that to ensure great UX Fenix needs a whitelist of Mozilla-vetted extensions and intend to never allow non-whitelisted ones". The more restrictive ones do cause doubt and uncertainty in the extension developer community.

As an optimistic person I tend to read your statement as "for now we're implementing only the APIs the most popular Recommended Extensions need and will provide a good way to install these extensions, but there will be no artificial barriers and it will be possible to install any AMO or signed-but-unlisted extension on Fenix if one has an extension link". Is this a correct interpretation? If not, could you please provide a correct one?

[lnicola]

We want to ensure that any add-on supported in the new Firefox for Android provides an exceptional, secure mobile experience to our users. To this end, we are prioritizing Recommended Extensions that are optimized for different screen sizes and cover common mobile use cases. 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. When an add-on you previously installed becomes supported, we will notify you.

Via https://blog.mozilla.org/addons/2020/02/06/ublock-origin-for-firefox-android-nightly/.

Still, please add a way to install other extensions. It's not like the recommended ones are particularly trustworthy. I'm running Fenix Nightly, it's not like I'm expecting an "exceptional experience" (a lot of the builds are broken); I can deal with extensions using their desktop UIs instead of mobile-optimized ones.

[tanriol]

This post still does not answer whether "not supported" means "they may work, we just do not advertise them", "you're on your own and your bugs may not be fixed in a reasonable timeframe" or "to ensure great UX installing these extensions will be impossible".

[serovar]

It is clear, in my opinion, that they cannot commit openly to full WebExtension support because, basically, you never know what could happen in the future or the problems that may arise, so they are, for now, focusing on Recommended Extensions, because they are the most used and the most important from a general use case perspective.

That said, there is no sane reason not to think that they are willing to support generic WebExtensions in the long term, but they will never say that until they will be sure that they can deliver with 100% certainty.

They followed this same approach with WebExtension support in the first phases of Fenix development, where they never openly stated that they would have added WebExtension support with 100% certainty, but in the end they delivered, so I am trustful.

Finally, I hope that, in the event there should be any issues with a "perfect" implementation of generic WebExtensions, there will be at least a less perfect one available for power users via about:config (since it could theoretically be possible, since there has been a moment in recent time when "unstable" generic WebExtension support was available in Reference Browser).

[dessant]

Public statements were a bit vague, but that's most likely because the details of how exactly extension support will be rolled out are still being worked on. Mozilla's public communication so far indicates that they plan to achieve general extension support by the end of 2020.

I maintain a couple of recommended extensions, and I was contacted in December regarding Search by Image to be included in the initial set of supported extensions. There are some small changes that need to be made to support the browser because of the incomplete API, and they also shared suggestions and UI mockups for improving how the extension integrates in the browser's user interface.

No guide has been shared yet for how to test our extensions to make the necessary changes, but that's expected to change. I'm sure that you'll be able to try out all kinds of extensions in the transition period, not just officially supported ones, we'll just have to wait a bit more for details to be shared.

[creesch]

I'm sure that you'll be able to try out all kinds of extensions in the transition period, not just officially supported ones, we'll just have to wait a bit more for details to be shared

The thing is though that my question which sparked all this was specifically asking about this. So it isn't them just being vague but rather answering in a way that seems to imply that this will not be the case.

I very much hope you are right, but again, that is why I specifically asked if it would be possible to do so.

[dannycolin]

Sincerely, this issue is to track the progress of WebExtension support not to hear people complaining. So stop flooding people notifications. If you aren't happy with a decision taken by the mozdevs, I invite you to contact them by email or on the official forum. Those two channels are the right place for that.

[pwd-github]

The issue posted was for WebExtension support. Defining what that means for Fenix is part of the process. Please leave unhelpful attempts to police this discussion elsewhere, such as email or official forums. Those two channels are the right place for that.

[Speciesx]

If you aren't happy with a decision taken by the mozdevs, I invite you to contact them by email or on the official forum. Those two channels are the right place for that.

Or better, use Kiwi browser, this android browser has a extension support.

[unixandria-xda]

@Speciesx of course, it's your choice. But don't clutter up this thread with this please :)

[vesta0]

Thank you everyone for your feedback so far. I’d like to clarify my earlier comment, as it might have left room for interpretation, and I apologize if this has caused misunderstanding.

Since Firefox Preview is built on a completely new foundation, this affects the APIs we can support in this early stage of the rollout. At the same time, we are excited about the enhanced performance, privacy, and security benefits of Firefox Preview, so we want to make it available to everyone as quickly as possible.

I mentioned that we will be building API support exclusively for the Recommended Extensions program, which is true for our near-term plans. We don’t expect this to be true in the long run. Prioritizing support for recommended extensions allows us to ensure that the first supported add-ons will be secure and work well on the new Firefox for Android.

While it is currently not possible to install other extensions, we would like to expand our support for them. There are add-ons that aren’t currently part of the Recommended Extensions program but are super useful on mobile. We’d like to find a place for those. We will be better able to plan for them once we support more APIs and make improvements to the overall developer and user experience.

We’ll keep you updated on our progress on the add-ons blog. If you’d like to discuss add-on support in Firefox for Android further, please head over to our community forum. As a gentle reminder, please remember that comments on this issue and our community forums are expected to adhere to Mozilla’s Community Participation Guidelines.

[madb1lly]

Well, I don't use uBlock origin so the current WebExtension support is unuseful to me. How is further support being prioritised? Is it by number of users of a specific Add-On? Is it by the most commonly used APIs? Or some other method?

[cadeyrn]

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

[madb1lly]

Hello @cadeyrn thank you, I had already read that. From my understanding it does not answer my questions:

How is further support being prioritised? Is it by number of users of a specific Add-On? Is it by the most commonly used APIs? Or some other method?

[cadeyrn]

Read below the headlines "Will more add-ons be supported in the future?" and "Will add-ons not part of the Recommended Extensions program ever be supported on the new Firefox for Android?". These parts are about prioritization.

[madb1lly]

@cadeyrn in my opinion they don't explicitly address my questions, however since you think that they do, please can you provide clear answers? Is support being prioritised based on number of users of a specific Add-On? Is it by the most commonly used APIs? Or some other method?

[pwd-github]

@madb1lly I would guess that at this point they're still unsure. I suspect that they're going to see how it goes with uBlock Origin before committing to anything or any specific road map.

I see that Billy's question got a couple of thumbs downs. I think his question was a fair one and thus to ask for clarification is also fair. It's okay to ask questions.

[Juraj-Masiar]

As you can see (and hear) in the last Show and tell (4:30), whole existing Firefox for Android API should be already (!!!) supported in Fenix:
https://mzl.la/add-on-demos-2020-02-20

[creesch]

As you can see (and hear) in the last Show and tell (4:30), whole existing Firefox for Android API should be already (!!!) supported in Fenix:
https://mzl.la/add-on-demos-2020-02-20

Except that they give no option to install any other webextension besides the ones they preapproved. In fact the FAQ posted after @vesta0's last reply here is even more definitive as she was in that supporting anything else is simply not on the horizon.

I am still of the opinion that closing of the webextensions to anything than preapproved extensions is a bad idea.

1. It means that only existing extensions can be made suitable for mobile so anyone having an idea specifically for a mobile only extension will not be able to do so.
2. Limiting it to only a few extensions only makes sure that the explicit way those extensions call on the api works. It doesn't expose issues around edge cases or simply around unused bits of the extension api. Even if you are not going to prioritize them right away you'd think you want to be aware of those issues as early as possible.
3. It really goes against the open nature of the internet Mozilla advocates.

[madb1lly]

Thanks @Juraj-Masiar. @creesch you're right, there's still no official way to enable or install other add-ons, which may be reasonable for the normal Firefox Preview but in Nightly it seems odd.

[creesch]

It seems I might have missed something from the demo (I didn't watch the entire video for obvious reasons), but it seems we can actually test extensions now with the latest web-ext?

[creesch]

And here is how you test your webextension as a developer

1. On your android device enable developer settings and enable debugging over USB.
2. Install ADB (android device bridge) which comes bundled with the android SDK, if you don't want the entire sdk download the platform tools windows url extract them and add the directory you added to the path.
3. Install web-ext globally.
4. Connect your phone via USB.
5. From your extension directory (where manifest.json is located) run web-ext to run your extension.
   web-ext run --target=firefox-android --android-device=<IDGOESHERE> --firefox-apk=org.mozilla.fenix.nightly
   Obviously you need to know your device id, simply run the command first without the --android-device flag and it will list the connected android devices (make sure to also accept on your device).

Frankly, it baffles me that nobody at Mozilla thought to communicate this here and instead resorted to the vague things as said in the FAQ and previously here. Developers of extensions also want to be prepared and get an idea of where things stand.

[vesta0]

This meta issue was created to track our first milestone: build the foundational support for WebExtensions and ship a few of the most used/wanted add-ons on mobile: uBlock origin, NoScript, HTTPS Everywhere, Privacy Badger, Dark Reader, and Search By Image. Since initial support has now landed, we will close this issue, and file separate ones to track future milestones. You can still follow the in progress/planned work here: https://github.com/orgs/mozilla-mobile/projects/44#card-26664450

If you’d like to learn more about our future plans, please keep an eye out on https://blog.mozilla.org/addons/