1079466 - Problems with add-on options on Android

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: Add-on Manager, defect, P3)

Description

[:Margaret Leibovic]

options.xul is terrible. XUL isn't well supported in Fennec, it looks bad, and it's very hard to style.

I think we should create a new JS module, named something like AddonOptions.jsm, which can provide APIs for add-on authors to create options UI for their add-ons.

For now, we can implement these APIs by creating HTML UI in about:addons, but creating this JS module layer will give us the flexibility to create native UI for this in the future if we want.

We can keep the current options.xul logic around as long as we still have the current add-ons manager, but we can deprecate it and encourage add-on authors to use the new system. This should help ease the transition if we do ever create a native add-ons manager.

Comment 1

[:Margaret Leibovic]

This would also fix some outstanding bugs with these XUL options.

Comment 2

[:Margaret Leibovic]

The add-on SDK already supports something like this:
https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/simple-prefs

I think taking a look at this would be a great place to start, and then the add-on SDK could just use our module to implement these APIs for mobile.

Comment 3

[:Margaret Leibovic]

See the code here for some implementation details:
https://github.com/mozilla/addon-sdk/blob/master/lib/sdk/preferences/native-options.js#L113

Comment 4

[:Margaret Leibovic]

Also, see documentation here about what's currently supported in options.xul:
https://developer.mozilla.org/en-US/Add-ons/Inline_Options#Setting_types

However, in reality, a bunch of these things probably don't work on mobile, hence a lot of the dependent bugs here.

I do have an add-on here that exercises some of these settings:
https://github.com/leibovic/options-kitchen-sink/

Comment 5

[:Margaret Leibovic]

Talked with Pierpaolo via email, he offered to take this on!

Comment 6

[Ray Lin[:ralin]]

Hi, Margaret!

I think this is a meaningful work, if possible, could I take this bug? Thanks.

Comment 7

[:Margaret Leibovic]

(In reply to Ray Lin[:ralin] from comment #6)
> Hi, Margaret!
> 
> I think this is a meaningful work, if possible, could I take this bug?
> Thanks.

Sure! This has been a pet peeve of mine for ages, it would be great to see it fixed.

However, we should also touch base with Andy and Kev from the add-ons team to understand what they'd like to see here. The end goal is to have web extensions be the "one true way" to write browser add-ons, so we should implement a system that would work with web extensions.

https://developer.mozilla.org/en-US/Add-ons/WebExtensions

Andy/Kev: How do web extensions create preferences UI (i.e. the UI that shows up in the add-on manager)? What types of things are supported?

Comment 8

[Andy McKay]

WebExtensions do this by implementing an API called options V2:

https://developer.chrome.com/extensions/optionsV2

On Desktop, this basically renders an iframe in the add-on details page like this:

https://ffp4g1ylyit3jdyti1hqcvtb-wpengine.netdna-ssl.com/addons/files/2016/04/image08.png

You can see an example add-on that does this here:

https://github.com/mdn/webextensions-examples/tree/master/favourite-colour

This is really simple, there's no XUL involved and storing that data is up to the developer.

Comment 9

[:Margaret Leibovic]

Thanks, Andy.

Since about:addons is an HTML page under the hood, we should be able to include an iframe.

It would be nice to support a way for non-web-extension add-ons to also create a similar iframe, but I don't know that it's worth investing in alternate solutions, if we want web extensions to be the future.

Comment 10

[Ray Lin[:ralin]]

imho, I suppose users can take benefit from both alternate solutions and web extensions format. Since not everyone like to write their own option page, auto-generated options page would be helpful for them. For those who prefer customized options page could take the flexibility from option v2. 

However, restrict users to stick on web extension could get rid of possible migration works in the further future.

Comment 11

[Andy McKay]

(In reply to Ray Lin[:ralin] from comment #10)
> Since not everyone like to write their own option page,
> auto-generated options page would be helpful for them. 

I would recommend against this. The technical debt for the project doesn't seem worth it when HTML is well documented and well understood.

Comment 12

[Christian Riechers]

FF for Android 52.0.1, Android 7.1.1 on Nexus 5X
The Options button is gone for add-ons which certainly do have configurable options.
Among others, I do have Adblock Plus and Self-Destructing Cookies installed. The options are not accessible anymore, but were in earlier versions of FF.
I only noticed this with FF52. However, there are reports on SUMO that this problem already started with FF51.

Comment 13

[Kevin Brosnan [Ex-Mozilla]]

Christian this is not the bug you are seeing. The issue you are seeing is bug 1329027.

Comment 14

[Andy McKay]

With WebExtensions options pages are now HTML and there's no desire to maintain any other option.