Hi, I tested a WebExtension of this kind on a desktop FF, and it works, but I am not sure if it does the same on an Android system (and currently I have not an Android Emulator…). Can you help me, saying me if that manifest pattern works also on an Android platform? Thanks.
Yes - that should work on Android. I use those.
Be aware that you cannot use options_ui yet on Android.
1 Like
I had assumed that the option-page was available, because it seemed like a basic function. I need a point from which the user can manage the we. Any suggestions to use some trick to replace it until it will be supported on Android?
Add support for options_ui on Android is bug 1302504
I have a couple of webextensions waiting for this. I don’t know a workaround. Maybe you can get at the prefs and set them there, but I don’t think so. I suppose you could write the options into local storage within a content script with a settings button and a new form. Not an easy or good solution; let’s hope the devs give options_ui some priority.
Other Android webextensions dependencies are listed in this tracker bug.
1 Like
I don’t know why the Android version is treated a bit like a Cinderella 
I think nowadays smartphones and tablets are as important as a desktop pc.
If I have correctly understood your idea, I can dynamically create a page options using a content script, previously informing the user to insert a particular unique url corresponding to that script, in order to access the page.
Accordingly to what the user choices, the page will communicate with the background script via messaging, and will produce this way the expected results (e.g. for storing data in the local.storage). Does your idea sound similar to all this?
This seems fine, considered also that I don’t need a real setting page (i.e. a place where set only persistent settings), but a page by means of which the user can interact in real time with the WE.
I hasten to add that ‘my idea’ was thought up in about 30 seconds after seeing your question; it’s not something I’d thought about before.
I have several content scripts that use local storage already for an ‘option’ - they were originally greasemonkey scripts - so I immediately thought of that. (And I have one that, once converted into an addon, copies such an option into a pref to make it proof from clearing local storage - which is the inverse of our problem now.)
Local storage has to be same-origin, so you must use a content script on the same website that you want to use the options for. I imagined adding a ‘settings’ button to some little-used page on that website, which brings up a form to enter the options. You might be able to reuse the webextensions options_ui form in some way.
Having now thought about it for another five minutes, it’s not such a bad idea! Especially since preferences/options on Android have been broken twice in the last couple of years - they’re broken now in 51 & 52.